@calltelemetry/ct-lab-mcp 0.8.93 → 0.8.94

package/README.md

@@ -97,7 +97,7 @@ than use the legacy Node VMID/name slot state when the bridge is unavailable.
 - **Remote Appliance CLI Control**: Mediated execution of `cli.sh` commands over SSH (port 2222) for status inspection, health diagnostics, Ecto migrations, table vacuums, and container logs.
 - **Leased Remote Development**: `lab_dev` is a canonical-only façade for the `ct-local-dev-v1` profile. It supports strict `doctor`, `plan`, `prepare`, `start`, `status`, `sync`, `stop`, and `cleanup` actions bound to one asset, lease, Linear issue, operation ID, and reviewed receipt chain. It accepts no guest commands, remote paths, or mock fallback.
 - **Claim custody annotation** (REL-1746; slots and reservation Leases are retired): Proxmox claim creation requires the actual canonical node, explicit VMID and VM name in `ct-lab`, with a finite TTL. The original-owner record lives on the claim itself as annotation `calltelemetry.com/claim-custody` (`claim-custody/v1`: guest tuple, phase, operation nonce, creation-request hash, context, provider binding), written in the same single create call as the claim. No Lease is ever created, renewed or required; per-guest serialization is in-process keyed by node and VMID, and the existing claim-occupancy scan plus the claim UID/resourceVersion protect against other actors. Whole effective immutable CRD fields and creation labels are rehashed on retry and deletion; only the declared lifecycle fields and stale label can change. A matching name alone grants no custody. Claims created before the retirement still carry a `ct-physical-slot-reservation.*` Lease: the MCP verifies them read-only (reporting `custody.source: "legacy-lease"`, `migration: "operator-pending"`) and the appliance operator converts them into the annotation; the MCP never writes a Lease.
-- **One configured Kubernetes claim backend**: ApplianceClaim CRUD and read-only legacy reservation Lease reads share one backend resolver. Local stdio deployments must set an absolute `LAB_CLAIM_KUBECONFIG`, the exact `LAB_CLAIM_K8S_CONTEXT`, and an HTTPS-origin `LAB_CLAIM_K8S_SERVER`; the selected kubeconfig is validated against that server before a request. In-cluster deployments must set the context/server and provide the service-account token and CA for that same cluster. Cross-cluster deployments use the explicit kubeconfig path. The process never falls back to `KUBECONFIG`, `~/.kube/config`, or an embedded server, and a missing or mismatched binding is refused before any claim effect. The Flux-managed consumer manifest `ct-infrastructure/clusters/doks-nyc1/apps/ct-lab/deploy-ct-lab-mcp.yaml` is a companion rollout change: the image-roll workflow refuses to update it until all three backend variables are present, and the kubeconfig path must be mounted from the selected cluster's protected configuration.
+- **One configured Kubernetes claim backend**: ApplianceClaim CRUD and read-only legacy reservation Lease reads share one backend resolver. Local stdio deployments must set an absolute `LAB_CLAIM_KUBECONFIG`, the exact `LAB_CLAIM_K8S_CONTEXT`, and an HTTPS-origin `LAB_CLAIM_K8S_SERVER`; the selected kubeconfig is validated against that server before a request. In-cluster deployments must set the context/server and provide the service-account token and CA for that same cluster. Cross-cluster deployments use the explicit kubeconfig path. The process never falls back to `KUBECONFIG`, `~/.kube/config`, or an embedded server, and a missing or mismatched binding is refused before any claim effect. The container image is published to Docker Hub by the Docker Build and Publish workflow, which only builds and pushes; it does not edit any cluster manifest. ct-lab-mcp is not Flux-deployed, and the retired DOKS cluster is no longer a target.
 - **Original UID deletion**: `delete_appliance_claim` requires `expectedUid` from the independently observed original claim. It verifies the claim custody record (or legacy Lease, read-only), then requests only claim deletion with UID/resourceVersion `DeleteOptions` preconditions; the operator owns teardown and must independently prove original guest, owned-volume and original-UID absence before releasing custody. A claim with neither a custody annotation nor a legacy Lease is refused (`NoClaimCustody`).
 - **Guarded image import**: `claimed_import_qcow` creates a bare claim, waits for an operator to set it `Ready` (default 120 s, `CT_LAB_CLAIM_RECONCILE_TIMEOUT_MS`; a claim no operator reconciles fails with `CLAIM_NOT_RECONCILED` before any image import, because the claim plane and the operator's cluster differ), then invokes the canonical `vm provision --source published-qcow` lifecycle. Its actual default bridge keeps host CPU semantics; portable first-power qualification uses the separate explicit canonical source route. Returned, thrown and uncertain import errors retain the claim and its custody record and preserve diagnostics. This path requires the qualified controller and operator successors; a source pin alone does not establish deployed readiness.
 - **Legacy SDK effects**: Direct SDK guest creation/clone/power/config/destruction, unguarded script guest writes and generic guest SSH authentication/commands are unavailable without the implemented canonical lifecycle. No caller flag or environment switch enables the retired effects. The historical purge daemon reports `authority_required` with zero releases/destruction and keeps all protection records. Provider inventory reads and implemented typed canonical operations remain available.

package/dist/src/tools/kubernetes-backend.d.ts

@@ -21,7 +21,7 @@ export interface KubernetesCommandOptions {
 }
 /**
  * Select exactly one backend. Local tools must receive the LAB_CLAIM_* tuple;
- * KUBECONFIG, ~/.kube/config, and an embedded DOKS endpoint are never defaults.
+ * KUBECONFIG, ~/.kube/config, and an embedded cluster endpoint are never defaults.
  */
 export declare function resolveLabKubernetesBackend(env?: NodeJS.ProcessEnv, existsSync?: (path: string) => boolean): LabKubernetesBackend;
 /** Run a local kubectl operation only after the selected kubeconfig is proven to match LAB_CLAIM_K8S_SERVER. */

package/dist/src/tools/kubernetes-backend.js

@@ -39,7 +39,7 @@ function configuredServer(env) {
 }
 /**
  * Select exactly one backend. Local tools must receive the LAB_CLAIM_* tuple;
- * KUBECONFIG, ~/.kube/config, and an embedded DOKS endpoint are never defaults.
+ * KUBECONFIG, ~/.kube/config, and an embedded cluster endpoint are never defaults.
  */
 export function resolveLabKubernetesBackend(env = process.env, existsSync = fs.existsSync) {
     const context = configuredContext(env);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@calltelemetry/ct-lab-mcp",
-  "version": "0.8.93",
+  "version": "0.8.94",
   "description": "Expanded Model Context Protocol (MCP) server for Call Telemetry lab, fleet, and appliance management across Proxmox VE and VMware ESXi.",
   "type": "module",
   "main": "./dist/src/index.js",