Domina las operaciones de KCC con Google Antigravity

1. Introducción

En este codelab, aprenderás sobre Google Antigravity (al que se hará referencia como Antigravity en el resto del documento), una plataforma de desarrollo basada en agentes que evoluciona el IDE hacia la era centrada en los agentes.

A diferencia de los asistentes de programación estándar que solo completan automáticamente líneas, Antigravity proporciona un "Centro de control" para administrar agentes autónomos que pueden planificar, programar e incluso navegar por la Web para ayudarte a crear.

Antigravity se diseñó como una plataforma centrada en los agentes. Se presupone que la IA no es solo una herramienta para escribir código, sino un actor autónomo capaz de planificar, ejecutar, validar y realizar iteraciones en tareas de ingeniería complejas con una intervención humana mínima.

Qué aprenderás

• Instalar y configurar Antigravity
• Explorar los conceptos clave de Antigravity, como Agent Manager, Editor, Browser y mucho más
• Compilar una habilidad de KCC de nivel de producción desde cero para administrar los recursos de Google Cloud con seguridad y cumplimiento

Requisitos

Actualmente, Antigravity está disponible como vista previa para las cuentas personales de Gmail. Incluye una cuota gratuita para usar modelos premium.

Antigravity debe estar instalado de forma local en tu sistema. El producto está disponible en Mac, Windows y distribuciones específicas de Linux. Además de tu propia máquina, necesitarás lo siguiente:

• Una cuenta de Gmail (cuenta personal de Gmail)
• Una cuenta de Google Cloud y un proyecto de Google Cloud
• Un navegador web, como Chrome, que admita la consola de Google Cloud y Cloud Shell

2. Configuración y requisitos

Configuración del proyecto

Crea un proyecto de Google Cloud

1. En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.
2. Asegúrate de que la facturación esté habilitada para tu proyecto de Cloud. Obtén información para verificar si la facturación está habilitada en un proyecto.

Este codelab está diseñado para usuarios y desarrolladores de todos los niveles (incluidos los principiantes).

3. Instalación

Si aún no tienes instalado Antigravity, comencemos con la instalación. Actualmente, el producto está disponible como versión preliminar y puedes usar tu cuenta personal de Gmail para comenzar a usarlo.

Ve a la página de descargas y haz clic en la versión del sistema operativo que corresponda a tu caso. Inicia el instalador de la aplicación y, luego, instálala en tu máquina. Una vez que completes la instalación, inicia la aplicación de Antigravity.

Pasos clave durante la configuración:

• Elige el flujo de configuración: Te recomendamos que comiences de cero para este codelab.
• Desarrollo basado en revisiones (recomendado): Elige esta opción. Permite que el agente tome una decisión y vuelva con el usuario para obtener su aprobación, lo que es fundamental para las operaciones de infraestructura.

A continuación, configura el editor y accede a Google. Por último, acepta las Condiciones de Uso.

4. Configuración de la infraestructura: GKE y Config Connector

Antes de compilar la skill, necesitas un entorno de Google Cloud con Config Connector (KCC) instalado de forma manual y configurado en el modo de espacio de nombres. Esto te permite administrar los recursos de GCP como objetos de Kubernetes.

Paso 0: Prepara tu entorno

1. Requisitos previos del clúster

Crea un clúster de GKE nuevo con las funciones necesarias habilitadas:

# Set your variables
export PROJECT_ID=$(gcloud config get-value project)
export CLUSTER_NAME="kcc-ops-cluster"
export REGION="us-central1"

# Create the cluster
gcloud container clusters create ${CLUSTER_NAME} \
    --region ${REGION} \
    --release-channel "regular" \
    --workload-pool=${PROJECT_ID}.svc.id.goog \
    --logging=SYSTEM \
    --monitoring=SYSTEM

# Get cluster credentials
gcloud container clusters get-credentials ${CLUSTER_NAME} --region ${REGION}

2. Instala el operador de Config Connector

El operador mantiene tu instalación actualizada.

# Download the latest Config Connector operator
gcloud storage cp gs://configconnector-operator/latest/release-bundle.tar.gz release-bundle.tar.gz

# Extract the bundle
tar zxvf release-bundle.tar.gz

# Install the operator (Standard Cluster)
kubectl apply -f operator-system/configconnector-operator.yaml

3. Configura el modo de espacio de nombres

Crea un recurso ConfigConnector para especificar el modo de funcionamiento.

# configconnector.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnector
metadata:
  name: configconnector.core.cnrm.cloud.google.com
spec:
  mode: namespaced
  stateIntoSpec: Absent

kubectl apply -f configconnector.yaml

4. Crea una identidad y un espacio de nombres

En este lab, usaremos el espacio de nombres default y una cuenta de servicio de Google (GSA) dedicada.

# Set your variables
export PROJECT_ID=$(gcloud config get-value project)
export NAMESPACE="default"

# Create the Google Service Account
gcloud iam service-accounts create kcc-identity --project ${PROJECT_ID}

# Grant permissions on the project
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/owner"

# Grant Metric Writer permissions
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/monitoring.metricWriter"

# Bind GSA to KSA via Workload Identity
gcloud iam service-accounts add-iam-policy-binding \
    kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com \
    --member="serviceAccount:${PROJECT_ID}.svc.id.goog[cnrm-system/cnrm-controller-manager-${NAMESPACE}]" \
    --role="roles/iam.workloadIdentityUser"

5. Configura el espacio de nombres

Crea un ConfigConnectorContext para observar el espacio de nombres.

# configconnectorcontext.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnectorContext
metadata:
  name: configconnectorcontext.core.cnrm.cloud.google.com
  namespace: default
spec:
  googleServiceAccount: "kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com"
  stateIntoSpec: Absent

kubectl apply -f configconnectorcontext.yaml

6. Verifica la instalación

Espera a que el controlador esté listo para el espacio de nombres default.

kubectl wait -n cnrm-system \
    --for=condition=Ready pod \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -l cnrm.cloud.google.com/scoped-namespace=default

5. Administrador de agentes: Centro de control

Antigravity bifurca la base de código abierto de Visual Studio Code (VS Code), pero altera radicalmente la experiencia del usuario para priorizar la administración de agentes por sobre la edición de texto. La interfaz se bifurca en dos ventanas principales distintas: Editor y Agent Manager.

Administrador de agentes

Cuando se inicia Antigravity, el usuario suele ver el Administrador de agentes. Esta interfaz actúa como un panel de Control de la misión. Está diseñado para la organización de alto nivel, lo que permite a los desarrolladores generar, supervisar e interactuar con varios agentes que operan de forma asíncrona en diferentes espacios de trabajo o tareas.

En esta vista, el desarrollador actúa como arquitecto. Definen objetivos de alto nivel. Cada una de estas solicitudes genera una instancia de agente dedicada. La IU proporciona una visualización de estos flujos de trabajo paralelos, en la que se muestra el estado de cada agente, los artefactos que produjo (planes, resultados, diferencias) y las solicitudes pendientes de aprobación humana.

6. Navegador y artefactos antigravedad

Antigravity crea artefactos a medida que planifica y realiza su trabajo. Estos son archivos Markdown enriquecidos, diagramas de arquitectura, imágenes, grabaciones del navegador y comparaciones de código.

Los artefactos resuelven la "brecha de confianza"

Cuando un agente afirma que corrigió el error, el desarrollador debía leer el código para verificarlo. En Antigravity, el agente produce un artefacto para demostrarlo.

Artefactos

Estos son los principales artefactos que produce Antigravity:

• Task Lists: Es un plan estructurado que se genera antes de escribir el código.
• Implementation Plan: Cambios arquitectónicos con detalles técnicos.
• Walkthrough: Es un resumen de los cambios y cómo probarlos.
• Browser Recordings: Son registros de video de las sesiones del navegador para la verificación de la IU.

Navegador Antigravity

Cuando el agente necesita interactuar con la Web, invoca un subagente del navegador. Este subagente puede hacer clic, desplazarse, escribir y leer los registros de la consola. Utiliza un modelo especializado para operar en las páginas que se abren en el navegador administrado por Antigravity.

7. Experiencia del editor

El editor conserva la familiaridad de VS Code. Incluye el explorador de archivos estándar, el resaltado de sintaxis y el ecosistema de extensiones.

Funciones del Editor de claves:

• Autocompletar: Sugerencias inteligentes que se aceptan presionando Tab
• Pestaña para importar: Sugiere agregar dependencias faltantes.
• Comandos (Cmd + I): Activa las sugerencias de completado intercaladas con lenguaje natural.
• Panel lateral del agente (Cmd + L): Activa o desactiva el panel del agente para hacer preguntas o consultar archivos con @.

8. Cómo enviar comentarios

La capacidad de recopilar tus comentarios sin esfuerzo es la base de Antigravity. Estos artefactos son una forma de proporcionar comentarios al agente en comentarios al estilo de Documentos de Google.

Cada vez que agregues un comentario a un plan o una tarea, asegúrate de enviarlo. Esto guía al agente en la dirección que deseas.

9. Cómo crear la skill de Operaciones de KCC

Ahora que comprendes la plataforma, creemos la habilidad de Operaciones de KCC.

Kubernetes Config Connector (KCC) te permite administrar recursos de GCP como objetos de K8s. Sin embargo, requiere rieles de seguridad para evitar la desviación de la configuración, los incumplimientos de cumplimiento y la recreación accidental de recursos.

Paso 1: Estructura la skill

En la raíz de tu espacio de trabajo, crea la estructura de directorios para tu skill:

mkdir -p .agents/skills/kcc-ops/scripts
mkdir -p .agents/skills/kcc-ops/resources/policies/templates
mkdir -p .agents/skills/kcc-ops/resources/policies/constraints

Paso 2: Crea el archivo SKILL.md (el cerebro)

El SKILL.md define los metadatos y la "regla de oro" principal del agente. Crea .agents/skills/kcc-ops/SKILL.md:

---
name: kcc-ops
description: Assists with Config Connector (KCC) configuration, resource generation, and troubleshooting on Google Cloud.
---

# Config Connector (KCC) Operations Skill

Use this skill to manage Google Cloud resources using Kubernetes-style configuration (Config Connector).

## 🛑 GOLDEN RULE: Separate Generation from Application

**NEVER generate and apply a manifest in a single autonomous step.**

1. **Craft:** Write the generated manifest to a local file.
2. **Analyze:** Present the manifest to the user. Perform Impact Analysis and Dry Runs. Explain the consequences of the change (e.g., "If this topic is deleted, the attached subscription becomes orphaned").
3. **Wait:** Pause execution and explicitly wait for user permission to proceed.
4. **Apply:** Only run `kubectl apply` *after* the user has reviewed the manifest and the impact analysis, and then unequivocally confirmed you should proceed.

## Core Responsibilities

0. **Context Verification**: Verify the execution context (cluster, namespace, GCP project, user account) with the user before performing any operations.
1. **Installation & Health**: Verify KCC is properly installed and healthy on the target cluster.
2. **Resource Inventory**: Query and summarize existing KCC resources within a namespace.
3. **Brownfield Bulk Export (Adoption)**: Export existing GCP project resources into valid KCC YAML manifests.
4. **Manifest Generation**: Generate valid YAML manifests for GCP resources using KCC CRDs.
5. **Impact Analysis**: Identify ancillary services and resources (e.g., Cloud Run, Apps) that depend on a resource being modified.
6. **Change Differentiation**: Generate diff summaries for resource edits to support change control.
7. **Policy Compliance**: Vet KCC manifests against OPA/Gatekeeper policies.
8. **Troubleshooting**: Analyze resource status, and consult the troubleshooting guide to resolve reconciliation issues.

## Guidelines for Operations

### 0. Context Verification

Before performing **any operations or executing commands** (including health checks), you **MUST** verify the current execution context and obtain explicit user confirmation.

1. **Read Context:** Use commands like `kubectl config current-context`, `kubectl config view --minify -o jsonpath='{.contexts[0].context.namespace}'`, `gcloud config get-value project`, and `gcloud config get-value account` to determine the active environment.
2. **Present & Ask:** Show this information to the user clearly (e.g., "I see my context is X, namespace is Y, project is Z, and account is A. Is this correct?").
3. **Wait:** Do not proceed with any other steps or scripts until the user has confirmed or provided corrections.

### 1. Installation & Health Check

Before performing operations, ensure the environment is ready:

- **Automation**: You MUST use `./scripts/check-health.sh` to verify namespaces, controllers, and CRDs. Do not use manual kubectl commands for health checks, as the script enforces standard formatting and context verification.

### 2. Resource Inventory & Discovery

To understand the current state of infrastructure:

- **Automation**: You MUST use `./scripts/inventory.sh` to get a summary table of all KCC resources. Do not use manual kubectl queries, as the script is optimized to securely discover all CRDs with context validation.

### 3. Manifest Structure

- All KCC resources belong to the `cnrm.cloud.google.com` API group.
- Use the `cnrm.cloud.google.com/project-id` annotation for cross-project resource management if not using Namespaced Mode.
- Always include `apiVersion`, `kind`, `metadata`, and `spec`.

### 4. Official Resource Reference (Agent Action)

When generating or troubleshooting manifests, you **must not guess** the API schema. Always consult the [Official Config Connector Reference](https://cloud.google.com/config-connector/docs/reference/overview) for the exact API version, kind, and required fields for the specific resource and cross reference with the official [github repository](https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/master/config/crds/resources).

### 5. Troubleshooting Checklist

When a resource is not reconciling (check `kubectl get <kind> <name> -o yaml`):

- **Ready Condition**: Look for `status.conditions` where `type: Ready` and `status: "False"`.
- **Reason/Message**: Check the `reason` and `message` fields in the status conditions.
- **Consult the Guide**: Immediately check `./resources/troubleshooting-guide.md` for definitions of the error reason (e.g. `DependencyInvalid`, `ManagementConflict`) and follow its resolution steps.
- **Common Issues**:
  - Permissions: The KCC service account lacks IAM roles.
  - Quotas: GCP project quota exceeded.
  - Conflicts: Resource already exists or is managed by another tool.
  - Immutable Fields: Attempting to change a field that requires resource recreation. Look for "Update failed" errors related to immutable fields.
  - Reference Resolution: Check if the resource is waiting for a dependency (e.g., `referenced project not found`).

### 6. Impact Analysis (Ancillary Services)

Before modifying a resource (e.g., GCS Bucket, Pub/Sub Topic), verify whatElse depends on it:

- **Reference Search (Cluster-wide)**: Search for other KCC resources that reference the item.

  ```bash
  # Example: Find resources referencing a bucket named 'my-data-bucket'
  kubectl get-all -n <namespace> -o yaml | grep -C 5 "my-data-bucket"
  ```

- **IAM-based Analysis**: Check for IAM Service Accounts that have roles on the specific resource. A Cloud Run job or GKE Workload Identity might be using those permissions.
- **Common Ancillary Dependencies**:
  - **Storage Buckets**: Look for Cloud Run/GKE mounts (CSI), Cloud Functions triggers, or Dataflow jobs.
  - **Networks**: Check for Firewall rules, Forwarding rules, and GKE cluster assignments.
  - **IAM Policies**: Changing a policy might break access for external applications not managed by KCC.
- **Resource Graph**: Use `gcloud asset search-all-resources` to find resources that might have implicit links.

### 3. Policy Compliance & Best Practices

Evaluate KCC manifests against security and governance policies. The vetting tool supports three source modes:

- **Built-in Mode (Default)**: Uses the skill's high-fidelity `v1beta1` library (300+ Anthos constraints).
  - `Usage: ./scripts/vet-policy.sh <manifest-path>`
- **Remote Mode**: Clones and vets against an external Git repository.
  - `Usage: ./scripts/vet-policy.sh <manifest-path> <repo-url> [git-ref]`
  - ⚠️ **Note**: External libraries like the legacy GCP Policy Library may be out-of-date and cause schema validation errors with modern `gator`.
- **Local Mode**: Vets against a local directory of policies.
  - `Usage: ./scripts/vet-policy.sh <manifest-path> /path/to/local/policies`

**Interaction Model:**

1. Call `./scripts/vet-policy.sh` with the appropriate arguments.
2. Interpret the `=== KCC Best Practices ===` and `=== OPA/Gatekeeper ===` reports.
3. Supplement automated findings with manual review for specific security features not yet covered by OPA (e.g., `publicAccessPrevention: enforced`, `versioning: {enabled: true}`).

  ```bash
  # Run the skill's helper script (repo URL and branch are optional)
  ./scripts/vet-policy.sh manifest.yaml [policy-repo-url] [policy-ref]
  ```

## Skill Assets

This skill includes additional resources to streamline operations:

- **`scripts/`**: Automation scripts (e.g., `vet-policy.sh`, `bulk-export.sh`).
- **`examples/`**: Reference KCC manifests (e.g., `restricted-bucket.yaml`).
- **`resources/`**: Common templates, documentation snippets, and troubleshooting guides (e.g., `troubleshooting-guide.md`).

### 4. Safety Rails for Applying Manifests

Before applying any KCC manifest update to an existing resource, you MUST:

- **Verify Immutable Fields**: Call `./scripts/verify-immutable.sh <manifest-path>` to detect updates to fields (like `location`, `name`, `project-id`) that trigger destructive resource recreation.
- **Explain Impact**: If destructive changes are detected, you MUST warn the user and explain the downtime/data loss implications before requesting approval.

### 5. Emergency Recovery & Troubleshooting

If a resource is stuck in a "Deletion" or "Error" state:

- **Check for Abondon Flag**: Check if the resource has the `cnrm.cloud.google.com/deletion-policy: abandon` annotation. If it does, you will need to remove the annotation and then force delete the resource.
- **Force Delete**: Call `./scripts/force-delete.sh <kind> <name> [namespace]` to bypass Kubernetes finalizers and remove the resource from the cluster.
- **Orphan Warning**: Inform the user that force-deleting a KCC object may leave an orphaned resource in Google Cloud that requires manual cleanup.

### 6. Change Differentiation

When editing an existing resource, always generate a diff to summarize the change for reviewers or Git history:

- **Local Diff**:

  ```bash
  # Diff a local file against the cluster state
  kubectl diff -f modified-resource.yaml
  ```

- **Commit Summary Template**:

  ```text
  [KCC Change] Update <ResourceName> (<Kind>)
  - Field 'spec.foo' changed from 'X' to 'Y'
  - Impact: Ancillary service <ServiceName> will see updated <Config>
  ```

### 9. Best Practices

- **Namespaced Mode**: Prefer namespaced mode for better isolation.
- **Sensitive Data**: Use `spec.credential.secretRef` or similar for sensitive fields.
- **Resource Naming**: Use consistent naming conventions that match your Kubernetes/GCP standards.
- **Annotations**:
  - `cnrm.cloud.google.com/deletion-policy: abandon`: Keep GCP resource on KCC deletion.
  - `cnrm.cloud.google.com/state-into-spec: absent`: Prevents KCC from syncing GCP state back into the Kubernetes object (useful for avoiding reconciliation loops on fields like node counts).

## Common Resource Examples

### Compute Instance

```yaml
apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeInstance
metadata:
  name: instance-sample
  annotations:
    cnrm.cloud.google.com/project-id: "my-project-id"
spec:
  machineType: n1-standard-1
  zone: us-central1-a
  bootDisk:
    initializeParams:
      sourceImage: projects/debian-cloud/global/images/family/debian-11
  networkInterface:
    - networkRef:
        name: default
```

### Storage Bucket

```yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: bucket-sample
spec:
  location: US
```

### Pub/Sub Topic & Subscription

```yaml
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  name: order-events-topic
---
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubSubscription
metadata:
  name: order-processor-sub
spec:
  topicRef:
    name: order-events-topic
  ackDeadlineSeconds: 30
```

Paso 3: Implementa la herramienta de inventario

Crea .agents/skills/kcc-ops/scripts/inventory.sh para descubrir recursos de KCC:

#!/bin/bash
# List all resources in the cnrm.cloud.google.com group
KCC_KINDS=$(kubectl api-resources --no-headers | awk '/\.cnrm\.cloud\.google\.com/ {print $1}')
KCC_KINDS_CSV=$(echo "$KCC_KINDS" | paste -sd, -)

printf "%-40s %-30s %-10s %s\n" "KIND" "NAME" "READY" "STATUS/MESSAGE"
kubectl get "$KCC_KINDS_CSV" -A -o custom-columns="KIND:.kind,NAME:.metadata.name,READY:.status.conditions[?(@.type=='Ready')].status,MSG:.status.conditions[?(@.type=='Ready')].message" --ignore-not-found --no-headers

Paso 4: Agrega la lógica de verificación de políticas

Crea .agents/skills/kcc-ops/scripts/vet-policy.sh. Esta secuencia de comandos usará gator para verificar los manifiestos según las políticas de OPA:

#!/bin/bash
MANIFEST=$1
SKILL_ROOT=$(dirname "$(dirname "$0")")
POLICY_SRC="$SKILL_ROOT/resources/policies"

echo "=== OPA/Gatekeeper Policy Vetting ==="
if command -v gator >/dev/null 2>&1; then
    gator test -f "$MANIFEST" -f "$POLICY_SRC/templates" -f "$POLICY_SRC/constraints"
else
    echo "Gator not found. Skipping OPA audit."
fi

Paso 5: Implementa la protección de campos inmutables

Este es un riel de seguridad fundamental. Crea .agents/skills/kcc-ops/scripts/verify-immutable.sh:

#!/bin/bash
MANIFEST=$1
KIND=$(grep "^kind:" "$MANIFEST" | awk '{print $2}')
NAME=$(grep "name:" "$MANIFEST" | head -n 1 | awk '{print $2}')

# Check for changes in common immutable fields
IMMUTABLE_FIELDS=("location" "project-id" "name" "zone" "region")
TEMP_FILE=$(mktemp)
kubectl get "$KIND" "$NAME" -o yaml > "$TEMP_FILE" 2>/dev/null

for field in "${IMMUTABLE_FIELDS[@]}"; do
    NEW=$(grep "$field:" "$MANIFEST" | awk '{print $2}')
    OLD=$(grep "$field:" "$TEMP_FILE" | awk '{print $2}')
    if [ -n "$NEW" ] && [ -n "$OLD" ] && [ "$NEW" != "$OLD" ]; then
        echo "🚨 WARNING: Immutable field '$field' is changing! Potential resource recreation."
    fi
done
rm "$TEMP_FILE"

Paso 6: Recuperación de emergencia (borrado forzado)

Crea .agents/skills/kcc-ops/scripts/force-delete.sh:

#!/bin/bash
KIND=$1; NAME=$2; NS=${3:-default}
echo "Removing finalizers for $KIND/$NAME in $NS..."
kubectl patch "$KIND" "$NAME" -n "$NS" -p '{"metadata":{"finalizers":null}}' --type=merge
kubectl delete "$KIND" "$NAME" -n "$NS" --wait=false

Paso 7: Finaliza los recursos

Haz que todas las secuencias de comandos sean ejecutables:

chmod +x .agents/skills/kcc-ops/scripts/*.sh

10. Prueba tu nueva Skill

Ahora, inicia una conversación nueva y pon a prueba tu habilidad:

1. Descubrimiento: @kcc-ops Show me all KCC resources in my cluster.
2. Cumplimiento: Crea un archivo bucket.yaml con un StorageBucket. Pregunta: @kcc-ops Vet my bucket.yaml manifest.
3. Seguridad: Intenta actualizar el location de un bucket existente en bucket.yaml. Pregunta: @kcc-ops Verify my bucket.yaml for immutable changes.

Observa cómo el agente elige de forma inteligente el guion correcto y sigue la "Regla de oro" de tu SKILL.md.

11. Protección del agente

Darle acceso a un agente de IA a tu terminal es una acción poderosa, pero requiere controles.

Ve a Antigravity > Settings > Terminal y explora las listas de bloqueo y listas de entidades permitidas.

• Lista de entidades permitidas: Agrega ls, kubectl get y tus secuencias de comandos de habilidad aquí.
• Lista de bloqueo: Agrega sudo, rm -rf o cualquier otro comando destructivo para garantizar que el agente SIEMPRE solicite permiso.

12. Conclusión

¡Felicitaciones! Pasaste de instalar Antigravity a crear una habilidad de operaciones de KCC de alta fidelidad.

Aprendiste lo siguiente:

• Cómo extender el agente con herramientas de Bash personalizadas
• Cómo codificar las "Reglas de oro" operacionales en un SKILL.md
• Cómo proporcionar rieles de seguridad para la administración de infraestructura compleja

Próximos pasos

Expande tu carpeta resources/policies con más restricciones de OPA o agrega una secuencia de comandos check-health.sh para automatizar las verificaciones de preparación del clúster.