Acting on a cluster

Five tools change a cluster. Each acts on one object in one namespace, takes a reason (at least eight characters, kept in the audit with the call), and answers what the object was and what it is now.

• kube_scale sets a deployment's or statefulset's replicas: --workload payments-api --namespace staging-payments --replicas 3. If an HPA keeps it within bounds, the answer says so: the HPA may scale it back.
• kube_rollout_restart replaces a workload's pods one by one, as kubectl rollout restart does, and names the revision it made.
• kube_rollout_undo takes a deployment back to the revision before the current one, or to --revision <n> (kube_rollout_history lists them). The answer names what changes: images, commands, environment names, resources.
• kube_delete_pod deletes one pod, never a workload, and says whether a controller starts another in its place.
• kube_apply applies one manifest by server-side apply, in two calls. The first is always a dry run: nothing changes, and the answer lists each field that would and a digest. The second names that digest with dryRun false, and applies exactly that manifest; a changed manifest, another's digest, or one older than 30 minutes is refused, and the agent remembers which dry runs it made itself. It takes a Deployment, StatefulSet, DaemonSet, Service, ConfigMap, Job, CronJob, Ingress, HorizontalPodAutoscaler or PodDisruptionBudget. Never a Secret, since its values would pass through the service, and never a role, a binding or anything cluster-wide. It takes the fields it sets from any other manager, as kubectl apply --server-side --force-conflicts does.

Who may. A write runs only where your role may write on the target's tier (and, where the role's grant there says Approval, once someone else approves it in Approvals), and is decided twice: by the service before the call leaves it, and by the agent before it touches the cluster. Owner writes everywhere; Operator writes below prod; Reader never writes. On prod the reason is required. A refusal is a sentence: "Operator cannot act on prod (production-payments matched rule production-*). Ask an Owner, or change the role in Policy."

Your AI client. It sees these tools only when your role writes somewhere and, through the service, only with an API token made with May also write in Settings, or a sign-in that allowed writing. At most a few writes a minute go through one token.

From the command line. Each is a command too: slate kube_scale --workload payments-api --namespace staging-payments --replicas 2 --reason "more room for the sale". A manifest is JSON, or a file: slate kube_apply --manifest @flags.yaml --namespace staging-payments --reason "turn on checkout v2", then the same with --dryRun=false --digest <digest>.

The audit. Every write is a row, here and in the workspace's Audit: who, the tool, the namespace's tier, the decision, and the arguments with the reason first.