Glossario: scope, context window, sandbox, skill, MCP, worktree e CI

I termini fondamentali

Scope: Il confine del task: cosa deve cambiare e cosa deve restare invariato. Uno scope chiaro impedisce che una correzione locale diventi un refactor dell’intero progetto.
Context window: La quantità di informazioni che il modello può considerare in una singola sessione. File, prompt, log e conversazione competono per questo spazio: più contenuto non significa sempre più comprensione.
Sandbox: Un ambiente isolato con permessi limitati. Serve a ridurre il danno possibile quando un agente esegue comandi, modifica file o usa la rete.
Skill: Un insieme riusabile di istruzioni specializzate per un tipo di lavoro. Può definire cosa leggere, quali regole seguire, quali tool usare e come verificare il risultato.
MCP: Model Context Protocol: uno standard con cui applicazioni AI possono scoprire e usare strumenti o fonti dati esposti da server compatibili.
Worktree: Una seconda directory di lavoro collegata allo stesso repository Git. Permette di lavorare su branch diversi in parallelo senza mescolare file e modifiche.
CI: Continuous Integration: controlli automatici eseguiti quando il codice viene pubblicato o proposto in una pull request, per esempio build, test, lint e scan di sicurezza.
Branch: Un riferimento Git che permette di sviluppare una modifica senza spostare direttamente la linea principale del progetto. Il branch isola la storia dei commit, non crea automaticamente un secondo ambiente o una seconda directory.
Commit: Una registrazione versionata di modifiche e metadati nel repository. Un commit utile descrive un cambiamento coerente e può essere revisionato, confrontato o annullato senza confonderlo con lavoro non collegato.
Pull request: Una proposta di integrare modifiche da un branch. Raccoglie diff, discussione, review e controlli automatici prima del merge; non è soltanto un messaggio che annuncia codice già deciso.
Dependency: Codice esterno da cui il progetto dipende direttamente o indirettamente. Aggiungerne una cambia manutenzione, aggiornamenti, licenza, bundle e superficie di rischio.
Rollback: Il piano per tornare a uno stato funzionante quando una modifica causa problemi. Può significare ripristinare un deploy, annullare un commit o applicare una migrazione inversa; va progettato prima dei cambiamenti ad alto rischio.

Come si collegano durante un task

Definisci lo scope della modifica.
Fornisci al modello il contesto necessario senza riempire inutilmente la context window.
Lascia che l’agente lavori con i permessi della sandbox.
Richiama una skill quando esiste un workflow specializzato.
Usa MCP solo per strumenti e dati realmente necessari.
Se lavori in parallelo, isola il task in un worktree.
Prima di integrare il risultato, lascia che la CI esegua i controlli automatici.

Scenario completo: una piccola feature attraversa tutti i termini

Supponi di aggiungere un filtro “solo articoli aggiornati”. Lo scope comprende controllo, stato del filtro e lista risultante; non comprende un redesign della pagina. Apri un branch dedicato e, se devi lavorare senza disturbare modifiche già presenti, puoi associarlo a un worktree separato.

L’agente riceve soltanto il contesto utile: componente della lista, modello dati e test collegati. La sandbox limita file, rete e comandi accessibili. Una skill può imporre il workflow di implementazione e verifica; un server MCP può fornire dati o strumenti esterni solo se necessari.

Dopo la modifica leggi il diff, esegui build e test, quindi crei un commit coerente. La pull request rende il cambiamento revisionabile e la CI ripete i controlli configurati. Se il filtro produce una regressione in produzione, il rollback definisce come rimuovere la modifica senza improvvisare.

Mappa del flusso

scope -> branch/worktree -> contesto -> sandbox
      -> skill/MCP se necessari -> diff -> test/build
      -> commit -> pull request -> CI -> merge
      -> monitoraggio -> eventuale rollback

Fraintendimenti comuni

“È in sandbox, quindi è sicuro”: dipende dai permessi concessi e dai dati accessibili.
“Più contesto è sempre meglio”: troppo rumore può nascondere le istruzioni importanti.
“La CI è verde, quindi non ci sono bug”: controlla solo ciò che è stato configurato.
“Una skill è un prompt lungo”: una buona skill codifica un workflow riusabile e verificabile.
“Un worktree è una copia scollegata”: condivide la storia Git del repository, ma mantiene separati i file di lavoro.

Come tradurre il riepilogo di un agente in domande concrete

Quando un agente dice “build verde”, chiedi quale comando ha eseguito e in quale ambiente. Quando dice “fuori scope”, chiedi quali file o comportamenti ha escluso. Quando cita la sandbox, chiedi quali permessi erano concessi. Le parole del glossario diventano utili solo quando portano a una prova osservabile.

La stessa regola vale per la CI: un controllo verde conferma soltanto ciò che quel workflow verifica. Se non esiste un test per il filtro appena aggiunto, il verde non prova che il filtro funzioni.

Domande di chiarimento

Affermazione: "I test passano"
Domanda: quale comando, quanti test e quale esito?

Affermazione: "La modifica è isolata"
Domanda: quale branch o worktree contiene il diff?

Affermazione: "La CI è verde"
Domanda: quali job coprono davvero questa feature?

Affermazione: "È sicuro perché è in sandbox"
Domanda: quali file, comandi e accessi di rete erano consentiti?

Affermazione: "Posso fare rollback"
Domanda: qual è il comando o la procedura e quali dati coinvolge?

Tre termini correlati

Acceptance criteria: Condizioni osservabili che stabiliscono quando il task è completato.
Diff: La rappresentazione delle righe aggiunte, rimosse o modificate rispetto a una versione precedente.
Secret: Un valore che concede accesso o prova un’identità, come API key, token, password o chiave privata.

Fonti primarie per approfondire

Le definizioni sono volutamente operative. Per sintassi, limiti e comportamento aggiornato usa sempre la documentazione dello strumento: Git per branch e worktree, GitHub per pull request e review, Model Context Protocol per MCP.