Como dominar as operações do KCC com o Google Antigravity

1. Introdução

Neste codelab, você vai aprender sobre o Google Antigravity (chamado de Antigravity no restante do documento), uma plataforma de desenvolvimento agêntico que evolui o IDE para a era focada em agentes.

Ao contrário dos assistentes de programação padrão que apenas preenchem linhas automaticamente, o Antigravity oferece uma "Central de comando" para gerenciar agentes autônomos que podem planejar, programar e até navegar na Web para ajudar você a criar.

O Antigravity foi projetado como uma plataforma focada em agentes. Ela pressupõe que a IA não é apenas uma ferramenta para escrever código, mas um agente autônomo capaz de planejar, executar, validar e iterar tarefas de engenharia complexas com intervenção humana mínima.

O que você vai aprender

• Instalar e configurar o Antigravity.
• Conheça os principais conceitos do Antigravity, como Agent Manager, Editor, Browser e muito mais.
• Como criar uma habilidade de operações do KCC de nível de produção do zero para gerenciar recursos do Google Cloud com segurança e compliance.

O que é necessário

No momento, o Antigravity está disponível como uma prévia para contas pessoais do Gmail. Ele vem com uma cota sem custo financeiro para usar modelos premium.

O Antigravity precisa ser instalado localmente no seu sistema. O produto está disponível para Mac, Windows e distribuições específicas do Linux. Além da sua máquina, você vai precisar do seguinte:

• Uma conta do Gmail (conta pessoal do Gmail).
• Uma conta e um projeto do Google Cloud
• Um navegador da Web, como o Chrome, que seja compatível com o console do Google Cloud e o Cloud Shell

2. Configuração e requisitos

Configuração do projeto

Criar um projeto do Google Cloud

1. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto na nuvem do Google Cloud.
2. Verifique se o faturamento está ativado para seu projeto do Cloud. Saiba como verificar se o faturamento está ativado em um projeto.

Este codelab foi criado para usuários e desenvolvedores de todos os níveis, inclusive iniciantes.

3. Instalação

Se você ainda não tiver o Antigravity instalado, vamos começar instalando o app. No momento, o produto está disponível para prévia, e você pode usar sua conta pessoal do Gmail para começar a usar.

Acesse a página de downloads e clique na versão do sistema operacional adequada ao seu caso. Inicie o instalador de aplicativos e instale-o na sua máquina. Depois de concluir a instalação, inicie o aplicativo Antigravity.

Principais etapas durante a configuração:

• Escolha o fluxo de configuração:recomendamos começar do zero para este codelab.
• Desenvolvimento orientado por revisão (recomendado): escolha essa opção. Isso permite que o agente tome uma decisão e volte ao usuário para aprovação, o que é fundamental para operações de infraestrutura.

Em seguida, configure o Editor e faça login no Google. Por fim, aceite os Termos de Uso.

4. Configuração da infraestrutura: GKE e Config Connector

Antes de criar a skill, você precisa de um ambiente do Google Cloud com o Config Connector (KCC) instalado manualmente e configurado no modo com namespace. Isso permite gerenciar recursos do GCP como objetos do Kubernetes.

Etapa 0: preparar o ambiente

1. Pré-requisitos do cluster

Crie um cluster do GKE com os recursos necessários ativados:

# 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. Instale o operador do Config Connector

O operador mantém sua instalação atualizada.

# 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. Configurar o modo com namespace

Crie um recurso ConfigConnector para especificar o modo de operação.

# 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. Criar uma identidade e um namespace

Neste laboratório, vamos usar o namespace default e uma conta de serviço do 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. Configurar o namespace

Crie um ConfigConnectorContext para observar o namespace.

# 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. Verificar instalação

Aguarde até que o controlador esteja pronto para o namespace 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. Gerente de agentes: controle de missão

O Antigravity faz um fork da base de código aberto do Visual Studio Code (VS Code), mas altera radicalmente a experiência do usuário para priorizar o gerenciamento de agentes em vez da edição de texto. A interface é dividida em duas janelas principais distintas: Editor e Agent Manager.

Gerente de agentes

Ao iniciar o Antigravity, o usuário geralmente é recebido pelo Gerenciador de agentes. Essa interface funciona como um painel da Central de controle. Ele foi projetado para orquestração de alto nível, permitindo que os desenvolvedores gerem, monitorem e interajam com vários agentes que operam de forma assíncrona em diferentes espaços de trabalho ou tarefas.

Nessa visão, o desenvolvedor atua como um arquiteto. Eles definem objetivos de alto nível. Cada uma dessas solicitações gera uma instância de agente dedicada. A interface mostra uma visualização desses fluxos de trabalho paralelos, exibindo o status de cada agente, os artefatos que eles produziram (planos, resultados, diferenças) e as solicitações pendentes de aprovação humana.

6. Navegador e artefatos antigravidade

O Antigravity cria artefatos ao planejar e realizar o trabalho. São arquivos Markdown avançados, diagramas de arquitetura, imagens, gravações de navegador e diferenças de código.

Os artefatos resolvem a "lacuna de confiança"

Quando um agente afirma: "Corrigi o bug", o desenvolvedor precisa ler o código para verificar. No Antigravity, o agente produz um artefato para provar isso.

Artefatos

Estes são os principais artefatos produzidos pela Antigravity:

• Task Lists: um plano estruturado gerado antes de escrever o código.
• Implementation Plan: mudanças arquitetadas com detalhes técnicos.
• Walkthrough: um resumo das mudanças e como testá-las.
• Browser Recordings: gravações em vídeo de sessões do navegador para verificação da interface.

Navegador Antigravity

Quando o agente precisa interagir com a Web, ele invoca um subagente de navegador. Esse subagente pode clicar, rolar, digitar e ler registros do console. Ele usa um modelo especializado para operar nas páginas abertas no navegador gerenciado pelo Antigravity.

7. Experiência do editor

O editor mantém a familiaridade do VS Code. Ele inclui o explorador de arquivos padrão, o destaque de sintaxe e o ecossistema de extensões.

Principais recursos do Editor:

• Preenchimento automático: sugestões inteligentes aceitas ao pressionar Tab.
• Guia para importar: sugere adicionar dependências ausentes.
• Comandos (Cmd + I): acione conclusões inline usando linguagem natural.
• Painel lateral do agente (Cmd + L): ative ou desative o painel do agente para fazer perguntas ou consultar arquivos usando @.

8. Enviar feedback

O principal recurso do Antigravity é a capacidade de coletar seu feedback sem esforço. Esses elementos são uma forma de dar feedback ao agente nos comentários no estilo do Google Docs.

Sempre que você adicionar um comentário a um plano ou tarefa, não se esqueça de enviar. Isso direciona o agente para o que você quer.

9. Como criar a habilidade de operações do KCC

Agora que você entende a plataforma, vamos criar a KCC Ops Skill.

O Kubernetes Config Connector (KCC) permite gerenciar recursos do GCP como objetos do K8s. No entanto, ele exige proteções para evitar desvios de configuração, violações de compliance e recriação acidental de recursos.

Etapa 1: estruturar a habilidade

Na raiz do espaço de trabalho, crie a estrutura de diretórios para sua 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

Etapa 2: criar o SKILL.md (o cérebro)

O SKILL.md define os metadados e a "regra de ouro" principal do agente. Crie .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
```

Etapa 3: implementar a ferramenta de inventário

Crie .agents/skills/kcc-ops/scripts/inventory.sh para descobrir recursos do 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

Etapa 4: adicionar a lógica de análise de políticas

Criar .agents/skills/kcc-ops/scripts/vet-policy.sh. Esse script vai usar gator para analisar manifestos em relação às políticas do 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

Etapa 5: implementar a proteção de campo imutável

Essa é uma proteção de segurança essencial. Crie .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"

Etapa 6: recuperação de emergência (exclusão forçada)

Crie .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

Etapa 7: finalizar recursos

Torne todos os scripts executáveis:

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

10. Testar sua nova habilidade

Agora, inicie uma nova conversa e teste sua habilidade:

1. Descoberta: @kcc-ops Show me all KCC resources in my cluster.
2. Conformidade: crie um arquivo bucket.yaml com um StorageBucket. Pergunte: @kcc-ops Vet my bucket.yaml manifest.
3. Segurança: tente atualizar o location de um bucket em bucket.yaml. Pergunte: @kcc-ops Verify my bucket.yaml for immutable changes.

Observe como o agente escolhe de forma inteligente o script correto e segue a "Regra de ouro" do seu SKILL.md.

11. Como proteger o agente

Dar acesso a um agente de IA ao seu terminal é poderoso, mas exige controles.

Acesse Antigravity - Configurações - Terminal e confira a Lista de permissões e a Lista de bloqueios.

• Lista de permissões: adicione ls, kubectl get e os scripts de habilidade aqui.
• Lista de bloqueio: adicione sudo, rm -rf ou outros comandos destrutivos para garantir que o agente SEMPRE peça permissão.

12. Conclusão

Parabéns! Você passou da instalação do Antigravity à criação de uma habilidade de operações do KCC de alta fidelidade.

Você aprendeu:

• Como estender o agente com ferramentas bash personalizadas.
• Como codificar "Regras de ouro" operacionais em um SKILL.md.
• Como fornecer proteções para o gerenciamento de infraestruturas complexas.

A seguir

Expanda sua pasta resources/policies com mais restrições do OPA ou adicione um script check-health.sh para automatizar as verificações de prontidão do cluster.