Kubernetes Manifest Apply Failure Retry Prompt

The full Kubernetes manifest YAML that was rejected by the API server

apiVersion: apps/v1 kind: Deployment metadata: name: web-app spec: replicas: 3 selector: matchLabels: app: web template: metadata: labels: app: web spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80

Must be valid YAML syntax even if semantically incorrect. Harness should parse with a YAML parser and reject empty or non-object documents. Minimum 1 resource definition required.

The exact error message returned by the Kubernetes API server when the manifest was rejected

Error from server (BadRequest): error when creating "deployment.yaml": Deployment in version "v1" cannot be handled as a Deployment: no kind "Deployment" is registered for version "apps/v1beta1"

Must be a non-empty string. Harness should check for standard error patterns: version mismatches, validation errors, conflict errors, forbidden errors. Truncated or redacted errors will degrade recovery quality.

The Kubernetes server version of the target cluster, used to validate API version compatibility

v1.29.0

Must match semver pattern. Harness should query the cluster's /version endpoint rather than relying on user input when possible. Used to filter deprecated or unavailable API versions in the corrected manifest.

The target namespace for the resource, used to validate namespace-scoped resource references and RBAC context

production-web

Must be a valid Kubernetes namespace name: lowercase RFC 1123 label, max 63 characters. Harness should verify the namespace exists on the target cluster before retry. Null allowed for cluster-scoped resources.

The OpenAPI schema or kubectl explain output for the target resource kind, used to validate field names, types, and required properties

{"properties":{"spec":{"properties":{"replicas":{"type":"integer"},"selector":{"type":"object","required":["matchLabels"]}}}}}

Must be a valid JSON schema fragment or structured resource definition. Harness should fetch this from the cluster's /openapi/v2 endpoint using the target GVK. Required for field-level correction validation.

The maximum number of correction-and-retry cycles allowed before escalating to a human operator

3

Must be a positive integer. Harness should enforce this as a hard limit. Set to 1 for single-shot correction, 3-5 for iterative recovery. Exceeding this value triggers the escalation path defined in the harness, not another prompt retry.

Additional context for human operators if the retry budget is exhausted, including runbook references and on-call contact

Runbook: k8s-deploy-failure-v2. On-call: sre-platform@example.com. Previous attempts: 3. Last error: field validation failed on spec.template.spec.containers[0].resources.limits

Must be a non-empty string when retry budget is exhausted. Harness should auto-populate with attempt history, timestamps, and error summaries. Used only in the escalation output, not in the retry prompt itself.

YAML string

Parse as valid YAML; validate against target cluster's live OpenAPI v3 schema for the specified apiVersion/kind; must differ from [ORIGINAL_MANIFEST]

string

Must match a version supported by the target cluster for the given kind; check via kubectl api-resources or cluster schema cache

string

Must be a valid Kubernetes resource kind; must match the kind in [ORIGINAL_MANIFEST] unless the error indicates a kind mismatch

string

Must conform to RFC 1123 subdomain naming (lowercase alphanumeric, -, .); length <= 253 characters; must match original name unless rename is the fix

string

If present, must exist on the target cluster; validate via kubectl get namespace or cluster state check; null allowed for cluster-scoped resources

string

Must be a non-empty, human-readable explanation of what was changed and why; max 500 characters; must reference the specific error message from [API_SERVER_ERROR]

string

If provided, must be a valid unified diff or YAML patch showing only the changed lines between [ORIGINAL_MANIFEST] and corrected_manifest; null allowed if no structured diff is generated

array of strings

If present, each element must be a non-empty string describing a potential concern (e.g., deprecated API version, missing resource limits); null allowed if no warnings

Output YAML passes strict validation against the target cluster's API version schema (e.g., kubectl --dry-run=server).

API server rejects the corrected manifest with a schema error different from the original failure.

Run kubectl apply --dry-run=server -f [CORRECTED_MANIFEST] and check for zero validation errors.

The specific error message from [ORIGINAL_ERROR] is no longer present when applying the corrected manifest.

The same error code or message reappears, indicating the root cause was not addressed.

Diff the error output of kubectl apply for the original vs. corrected manifest; the original error string must be absent.

The diff between [ORIGINAL_MANIFEST] and [CORRECTED_MANIFEST] contains only changes necessary to resolve the error.

The corrected manifest introduces unrelated field additions, deletions, or reordering beyond the fix scope.

Generate a unified diff; non-fix changes (e.g., label additions, annotation reformatting) trigger a review flag.

Corrected values (e.g., image tags, port numbers, resource limits) match known-good references from [CLUSTER_CONTEXT] or [VALUES_FILE].

A corrected value references a non-existent resource, invalid image, or out-of-range port.

Cross-reference image registries, service endpoints, and quota specs defined in [CLUSTER_CONTEXT].

Corrected manifest does not introduce privilege escalations, hostPath mounts, or overly permissive RBAC beyond the original intent.

Security scanner flags new privileged: true, allowPrivilegeEscalation, or unrestricted capabilities.

Run a policy check with kubectl dry-run + OPA/Gatekeeper or Kyverno against the cluster's baseline policy set.

Applying the corrected manifest twice produces no state change on the second apply.

Second apply returns a conflict, resource version mismatch, or unintended update.

Execute kubectl apply twice in sequence; the second command must return unchanged or configured with no spec diff.

The resource created by the corrected manifest reaches a Ready state within [READINESS_TIMEOUT].

Pod stays in CrashLoopBackOff, Pending, or ImagePullBackOff after correction.

Run kubectl wait --for=condition=Ready --timeout=[READINESS_TIMEOUT] on the applied resource.

The correction is proposed within the allowed retry count defined in [RETRY_BUDGET]; escalation is triggered if the budget is exhausted.

The harness loops beyond [RETRY_BUDGET] without escalating or returns a manifest that still fails schema validation.

Assert that the retry loop counter increments and that the harness returns an ESCALATION_REQUIRED signal after [RETRY_BUDGET] exhausted failures.