Padroneggiare le operazioni KCC con Google Antigravity

1. Introduzione

In questo codelab, imparerai a utilizzare Google Antigravity (denominato Antigravity per il resto del documento), una piattaforma di sviluppo agentica che fa evolvere l'IDE nell'era agent-first.

A differenza degli assistenti di programmazione standard che completano automaticamente le righe, Antigravity fornisce un "centro di controllo" per la gestione di agenti autonomi in grado di pianificare, programmare e persino navigare sul web per aiutarti a creare.

Antigravity è progettata come piattaforma agent-first. Presuppone che l'AI non sia solo uno strumento per scrivere codice, ma un attore autonomo in grado di pianificare, eseguire, convalidare e ripetere attività di ingegneria complesse con un intervento umano minimo.

Cosa imparerai a fare

• Installazione e configurazione di Antigravity.
• Esplorare i concetti chiave di Antigravity come Agent Manager, Editor, Browser e altro ancora.
• Creazione di una skill KCC Ops di livello di produzione da zero per gestire le risorse Google Cloud in modo sicuro e conforme.

Che cosa ti serve

Al momento Antigravity è disponibile in anteprima per gli account Gmail personali. È dotato di una quota senza costi per l'utilizzo di modelli di primo livello.

Antigravity deve essere installato localmente sul tuo sistema. Il prodotto è disponibile su Mac, Windows e distribuzioni Linux specifiche. Oltre alla tua macchina, avrai bisogno di quanto segue:

• Un account Gmail (account Gmail personale).
• Un account Google Cloud e un progetto Google Cloud
• Un browser web come Chrome che supporta la console Google Cloud e Cloud Shell

2. Configurazione e requisiti

Configurazione del progetto

Crea un progetto Google Cloud

1. Nella console Google Cloud, nella pagina di selezione del progetto, seleziona o crea un progetto Google Cloud.
2. Verifica che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata per un progetto.

Questo codelab è pensato per utenti e sviluppatori di tutti i livelli (inclusi i principianti).

3. Installazione

Se non hai ancora installato Antigravity, iniziamo con l'installazione. Al momento il prodotto è disponibile in anteprima e puoi iniziare a utilizzarlo con il tuo account Gmail personale.

Vai alla pagina Download e fai clic sulla versione del sistema operativo appropriata per il tuo caso. Avvia il programma di installazione dell'applicazione e installala sul tuo computer. Una volta completata l'installazione, avvia l'applicazione Antigravity.

Passaggi chiave durante la configurazione:

• Scegli il flusso di configurazione:ti consigliamo di iniziare da zero per questo codelab.
• Sviluppo basato sulle recensioni (opzione consigliata): scegli questa opzione. Consente all'agente di prendere una decisione e tornare dall'utente per l'approvazione, il che è fondamentale per le operazioni dell'infrastruttura.

Dopodiché, configura l'editor e accedi a Google. Infine, accetta i Termini e condizioni d'uso.

4. Configurazione dell'infrastruttura: GKE e Config Connector

Prima di poter creare la skill, devi disporre di un ambiente Google Cloud con Config Connector (KCC) installato manualmente e configurato in modalità con spazi dei nomi. Ciò consente di gestire le risorse GCP come oggetti Kubernetes.

Passaggio 0: prepara l'ambiente

1. Prerequisiti del cluster

Crea un nuovo cluster GKE con le funzionalità necessarie abilitate:

# 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. Installa l'operatore Config Connector

L'operatore mantiene aggiornata l'installazione.

# 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. Configurare la modalità con spazio dei nomi

Crea una risorsa ConfigConnector per specificare la modalità di funzionamento.

# 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 un'identità e uno spazio dei nomi

Per questo lab, utilizzeremo lo spazio dei nomi default e un service account Google (GSA) dedicato.

# 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 lo spazio dei nomi

Crea un ConfigConnectorContext per monitorare lo spazio dei nomi.

# 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 dell'installazione

Attendi che il controller sia pronto per lo spazio dei nomi 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. Agent Manager: Mission Control

Antigravity si basa sul codice open source di Visual Studio Code (VS Code), ma modifica radicalmente l'esperienza utente per dare la priorità alla gestione degli agenti rispetto all'editing di testo. L'interfaccia è suddivisa in due finestre principali distinte: Editor e Agent Manager.

Agent Manager

All'avvio di Antigravity, l'utente viene in genere accolto da Agent Manager. Questa interfaccia funge da dashboard Mission Control. È progettato per l'orchestrazione di alto livello, consentendo agli sviluppatori di generare, monitorare e interagire con più agenti che operano in modo asincrono in diversi spazi di lavoro o attività.

In questa visualizzazione, lo sviluppatore funge da architetto. Definiscono gli obiettivi di alto livello. Ciascuna di queste richieste genera un'istanza dell'agente dedicata. L'interfaccia utente fornisce una visualizzazione di questi flussi di lavoro paralleli, mostrando lo stato di ogni agente, gli artefatti che ha prodotto (piani, risultati, differenze) e le richieste in attesa di approvazione umana.

6. Antigravity Browser & Artifacts

Antigravity crea artefatti mentre pianifica e svolge il suo lavoro. Si tratta di file markdown avanzati, diagrammi di architettura, immagini, registrazioni del browser e differenze di codice.

Gli artefatti colmano il "divario di fiducia"

Quando un agente afferma: "Ho corretto il bug", lo sviluppatore doveva leggere il codice per verificare. In Antigravity, l'agente produce un artefatto per dimostrarlo.

Artefatti

Di seguito sono riportati gli artefatti principali prodotti da Antigravity:

• Task Lists: un piano strutturato generato prima di scrivere il codice.
• Implementation Plan: Modifiche architettate con dettagli tecnici.
• Walkthrough: un riepilogo delle modifiche e come testarle.
• Browser Recordings: Registrazioni video delle sessioni del browser per la verifica dell'interfaccia utente.

Browser Antigravity

Quando l'agente deve interagire con il web, richiama un subagente browser. Questo subagente può fare clic, scorrere, digitare e leggere i log della console. Utilizza un modello specializzato per operare sulle pagine aperte nel browser gestito da Antigravity.

7. Esperienza dell'editor

L'editor mantiene la familiarità di VS Code. Include l'esplora file standard, l'evidenziazione della sintassi e l'ecosistema delle estensioni.

Funzionalità dell'editor di chiavi:

• Completamento automatico: suggerimenti intelligenti accettati premendo Tab.
• Scheda da importare: suggerisce di aggiungere le dipendenze mancanti.
• Comandi (Cmd + I): attiva i completamenti in linea utilizzando il linguaggio naturale.
• Riquadro laterale dell'agente (Cmd + L): attiva/disattiva il riquadro dell'agente per porre domande o fare riferimento a file utilizzando @.

8. Fornire feedback

Il punto di forza di Antigravity è la sua capacità di raccogliere facilmente i feedback. Questi artefatti ti consentono di fornire feedback all'agente in commenti in stile Documenti Google.

Ogni volta che aggiungi un commento a un piano o a un'attività, assicurati di inviarlo. In questo modo, l'agente si muoverà nella direzione che preferisci.

9. Creazione della skill KCC Ops

Ora che hai compreso la piattaforma, creiamo la skill KCC Ops.

Kubernetes Config Connector (KCC) consente di gestire le risorse GCP come oggetti K8s. Tuttavia, richiede protezioni per evitare la deriva della configurazione, le violazioni della conformità e la ricreazione accidentale delle risorse.

Passaggio 1: struttura la skill

Nella directory root dello spazio di lavoro, crea la struttura di directory per la tua 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

Passaggio 2: crea il file SKILL.md (il cervello)

SKILL.md definisce i metadati e la "regola d'oro" principale per l'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
```

Passaggio 3: implementa lo strumento per l'inventario

Crea .agents/skills/kcc-ops/scripts/inventory.sh per scoprire le risorse 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

Passaggio 4: aggiungi la logica di verifica dei criteri

Crea .agents/skills/kcc-ops/scripts/vet-policy.sh. Questo script utilizzerà gator per verificare i manifest in base alle norme 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

Passaggio 5: implementa la protezione dei campi immutabili

Si tratta di una funzionalità di sicurezza fondamentale. 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"

Passaggio 6: ripristino di emergenza (eliminazione forzata)

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

Passaggio 7: finalizza le risorse

Rendi eseguibili tutti gli script:

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

10. Test della tua nuova skill

Ora, avvia una nuova conversazione e metti alla prova la tua abilità:

1. Discovery: @kcc-ops Show me all KCC resources in my cluster.
2. Conformità: crea un file bucket.yaml con un StorageBucket. Chiedi: @kcc-ops Vet my bucket.yaml manifest.
3. Sicurezza: prova ad aggiornare location di un bucket esistente in bucket.yaml. Chiedi: @kcc-ops Verify my bucket.yaml for immutable changes.

Nota come l'agente scelga in modo intelligente lo script corretto e segua la "regola d'oro" del tuo SKILL.md.

11. Fissare l'agente

Concedere a un agente AI l'accesso al tuo terminale è potente, ma richiede controlli.

Vai a Antigravity - Settings - Terminal (Antigravity - Impostazioni - Terminale) ed esplora Allow List (Lista consentita) e Deny List (Lista bloccata).

• Lista consentita: aggiungi qui ls, kubectl get e gli script delle tue skill.
• Elenco di negazione: aggiungi sudo, rm -rf o altri comandi distruttivi per assicurarti che l'agente chieda SEMPRE l'autorizzazione.

12. Conclusione

Complimenti! Sei passato dall'installazione di Antigravity alla creazione di una skill per le operazioni del KCC ad alta fedeltà.

Hai imparato:

• Come estendere l'agente con strumenti bash personalizzati.
• Come codificare le "regole d'oro" operative in un SKILL.md.
• Come fornire guide di sicurezza per la gestione di infrastrutture complesse.

Passaggi successivi

Espandi la cartella resources/policies con altri vincoli OPA o aggiungi uno script check-health.sh per automatizzare i controlli di preparazione del cluster.