Start here. Given a project directory, report which Docker artefacts it contains: Dockerfile(s), a Compose file, .env files, source directories, dependency files and the names of the Compose services. Secret values are never returned.

Parse a Dockerfile into the facts a migration needs: base images and build stages, EXPOSE ports, WORKDIR, USER, ENTRYPOINT/CMD, declared ENV keys and the HEALTHCHECK. Use it to learn which port an image actually listens on.

Parse a Compose file into normalised services: images, build contexts, port mappings, environment, env_file, volumes, depends_on, healthchecks, restart policy, networks and resource limits. Values that look like credentials are returned as and listed by key in secret_keys.

List the environment variables the project uses, from .env files and from Compose, and classify each as configuration or secret. Secret VALUES are never returned -- only the key names -- so this is safe to call on a project with real credentials.

Explain how this project's Docker concepts map to Kubernetes: containers to Deployments or StatefulSets, port mappings to Services, environment to ConfigMaps and Secrets, volumes to PersistentVolumeClaims, HEALTHCHECK to readiness and liveness probes, and Compose service names to Service DNS. Also reports what cannot be migrated automatically (bind mounts, depends_on ordering, locally built images) as warnings and blockers.

Build the concrete, reviewable migration plan: per-service workload kind, replicas, images, ports, ConfigMap/Secret split, volumes, probes and resources, plus flat summaries of resources, ports, environment variables, secrets, volumes and healthchecks, with warnings and manual_steps. SHOW THIS PLAN TO THE USER before generating or deploying anything. Nothing is written to disk and no cluster is touched.

Write Kubernetes YAML for the project into a per-project directory under the server's generated/ folder. Only the resources the application actually needs are produced: a stateless service gets a Deployment, Service and ConfigMap, while a database also gets a StatefulSet with volumeClaimTemplates and a headless Service. Secrets are written with placeholders, never real credentials. The plan is re-derived from the project, so pass the same namespace/image_registry you passed to create_migration_plan. Writes files only -- it does not touch a cluster.

Check manifests for the mistakes that survive 'kubectl apply' but break the application: selectors that match no pods, a Service targetPort no container listens on, probes aimed at the wrong port, references to a ConfigMap, Secret or PVC that does not exist, undefined volume mounts, duplicate resources, wrong apiVersion, invalid names and out-of-range nodePorts. ALWAYS run this before deploying. Returns valid=false with human-readable errors when the manifests would break.

Confirm a Kubernetes cluster is reachable and list its nodes and namespaces. Call this before deploying so a connection problem is not mistaken for a deployment failure.

DEPLOY. This writes to the cluster and changes running workloads. Requires approved=true, which you may only pass after the user has seen the migration plan and its warnings and has explicitly said to deploy. Do not infer approval from the original request. Run validate_manifests first; this tool refuses to apply manifests that fail validation. Use dry_run=true to have the API server check the manifests without changing anything -- a dry run needs no approval.

Report desired vs ready replicas and the rollout conditions for a Deployment, falling back to a StatefulSet of the same name.

List pods with phase, ready count, restart count and any detected problem (CrashLoopBackOff, ImagePullBackOff, Pending, OOMKilled, CreateContainerConfigError). Use this first when a deployment looks unhealthy.

Read a pod's container logs. For a crash-looping pod set previous=true to read the instance that already died -- that is where the real error is.

List Services with their type, ports, selector and endpoint count. A Service with zero endpoints is the usual reason an application is unreachable even though its pods look fine.

Return recent Kubernetes events, oldest first. Events explain scheduling failures, image pull errors, probe failures and volume mount problems that the pod status alone does not.

Run the post-deployment checks in one call: the workload exists, ready replicas match desired, pods are Running and Ready, restart counts are zero, Services exist and have endpoints, and optionally that a health endpoint responds through the API server proxy. Never assume a deployment succeeded -- call this. If healthy is false, call diagnose_deployment.

Gather pods, container states, Services and warning events, and return a diagnosis: what is wrong, the evidence, the likely cause and a suggested fix. Recognises CrashLoopBackOff, ImagePullBackOff, Pending, OOMKilled, CreateContainerConfigError, failing probes, Services without endpoints and PVC problems. Call this whenever verify_deployment reports healthy=false.