Copilot Spaces, Agentic Memory e Repository Indexing
Uno dei fattori più' critici che determina la qualità' delle risposte di un assistente AI e' il contesto. Più' un modello di linguaggio comprende il tuo progetto, le tue convenzioni e i tuoi obiettivi, migliori saranno i suggerimenti che produce. Fino a poco tempo fa, fornire contesto a Copilot richiedeva sforzi manuali: aprire file rilevanti, scrivere prompt dettagliati, ripetere informazioni gia' fornite in sessioni precedenti.
Con l'introduzione di Copilot Spaces, Agentic Memory e i miglioramenti al Repository Indexing, GitHub ha affrontato questo problema in modo strutturale. Questi tre strumenti lavorano in sinergia per garantire che Copilot abbia sempre il contesto giusto al momento giusto, riducendo drasticamente la necessità' di ripetere informazioni e migliorando la coerenza delle risposte nel tempo.
In questo quattordicesimo articolo della serie, esploreremo in dettaglio ciascuno di questi strumenti: come funzionano, come configurarli e come utilizzarli al meglio per massimizzare la produttività' nel lavoro quotidiano.
Panoramica della Serie Completa
| # | Articolo | Focus |
|---|---|---|
| 1 | Foundation e Mindset | Setup e mentalita' |
| 2 | Ideazione e Requisiti | Da idea a MVP |
| 3 | Architettura Backend | API e database |
| 4 | Struttura Frontend | UI e componenti |
| 5 | Prompt Engineering | Prompt e Agenti MCP |
| 6 | Testing e qualità' | Unit, integration, E2E |
| 7 | Documentazione | README, API docs, ADR |
| 8 | Deploy e DevOps | Docker, CI/CD |
| 9 | Evoluzione | Scalabilità' e manutenzione |
| 10 | Coding Agent | Agente autonomo di sviluppo |
| 11 | Code Review | Review automatica AI |
| 12 | Copilot Edits | Editing multi-file |
| 13 | GitHub Spark | App da linguaggio naturale |
| 14 | Sei qui → Spaces e Memory | Contesto organizzato e memoria |
| 15 | Modelli AI | Guida alla scelta del modello |
| 16 | Personalizzazione | Custom instructions e knowledge |
| 17 | Enterprise | Copilot per organizzazioni |
| 18 | Extensions | Estendere Copilot con tool |
| 19 | Sicurezza | Sicurezza e compliance AI |
Copilot Spaces: Organizzare il Contesto per Conversazioni Mirate
Copilot Spaces e' una funzionalità' che permette di creare raccolte organizzate di contesto per conversazioni con Copilot. Uno Space e' essenzialmente un contenitore dove puoi includere diversi tipi di informazioni rilevanti per un determinato task, progetto o area di lavoro. Invece di dover spiegare ogni volta a Copilot su cosa stai lavorando, crei uno Space una volta e lo riutilizzi per tutte le conversazioni relative a quel contesto.
Cosa Puoi Includere in uno Space
La forza di Spaces risiede nella flessibilità' dei tipi di contenuto supportati. Non sei limitato al solo codice: puoi includere qualsiasi informazione utile per dare a Copilot il contesto necessario.
Tipi di Contenuto Supportati
| Tipo | Descrizione | Esempio di Utilizzo |
|---|---|---|
| Repository | Interi repository GitHub o cartelle specifiche | Includere il repo principale del progetto |
| File di codice | Singoli file o selezioni di codice | Il modello dati, le API principali, i config file |
| Pull Request | PR aperte o chiuse con diff e commenti | PR recenti per capire le ultime modifiche |
| Issue | Issue GitHub con discussioni | Bug aperti, feature request, decisioni architetturali |
| Testo libero | Note, istruzioni, context in formato testo | Convenzioni del team, regole di business, requisiti |
| Immagini | Screenshot, diagrammi, wireframe | Design di riferimento, diagrammi architetturali |
| File caricati | Documenti, PDF, file di configurazione | Specifiche tecniche, documenti di requirements |
Smart Loading: Contesto Intelligente
Un aspetto fondamentale di Spaces e' il meccanismo di Smart Loading. Quando includi un repository in uno Space, Copilot non carica l'intero contenuto del repository nel contesto della conversazione. Questo sarebbe impossibile per repository di grandi dimensioni e inefficiente anche per quelli piccoli.
Invece, Smart Loading funziona in modo simile a un motore di ricerca semantico: quando fai una domanda, Copilot cerca e recupera dinamicamente solo i file e le sezioni di codice rilevanti per la tua richiesta specifica. Questo approccio offre il meglio di entrambi i mondi: hai accesso all'intero repository come fonte di contesto, ma solo le parti rilevanti occupano la finestra di contesto del modello.
Come Funziona Smart Loading
- Indicizzazione: Quando aggiungi un repository allo Space, viene indicizzato per ricerca semantica
- Query: Quando fai una domanda, Copilot analizza l'intento e identifica i topic rilevanti
- Retrieval: I file e le sezioni pertinenti vengono recuperati dall'indice
- Ranking: I risultati vengono ordinati per rilevanza
- Context Assembly: Solo i frammenti più' rilevanti vengono inclusi nel prompt al modello
- Risposta: Il modello genera la risposta con contesto preciso e pertinente
Creare e Gestire Spaces
La creazione di uno Space avviene tramite l'interfaccia web di GitHub o direttamente dall'IDE. Il processo e' semplice e intuitivo.
Creazione di uno Space per un Progetto
SPACE: "E-commerce Backend"
REPOSITORY INCLUSI:
- org/ecommerce-api (repository principale)
- org/shared-libs (librerie condivise)
- org/ecommerce-docs (documentazione)
FILE SPECIFICI:
- ecommerce-api/src/models/*.ts (tutti i modelli dati)
- ecommerce-api/prisma/schema.prisma (schema database)
- ecommerce-api/.copilot-instructions.md (convenzioni del progetto)
- ecommerce-api/docs/architecture.md (decisioni architetturali)
ISSUE INCLUSE:
- #234: "Migrare a Event-Driven Architecture" (in discussione)
- #267: "Performance degradation on product search" (bug critico)
TESTO LIBERO:
"Questo progetto usa NestJS con Prisma ORM. Il database e' PostgreSQL.
L'autenticazione e' basata su JWT con refresh token.
Le API seguono il pattern CQRS con event sourcing per gli ordini.
Usiamo il pattern Repository per l'accesso ai dati.
I test seguono la piramide: 70% unit, 20% integration, 10% E2E.
Il deploy avviene tramite GitHub Actions su AWS ECS."Casi d'Uso per Spaces
Spaces e' particolarmente utile in scenari dove il contesto e' complesso, distribuito su più' repository o dove diverse persone del team lavorano su aspetti diversi dello stesso progetto.
Scenari d'Uso Comuni
| Scenario | Space Consigliato | Contenuti da Includere |
|---|---|---|
| Progetto multi-repo | Uno Space per progetto | Tutti i repo, schema condiviso, docs architetturali |
| Onboarding nuovo membro | "Onboarding [Progetto]" | README, guide setup, ADR, convenzioni, FAQ |
| Bug investigation | "Debug [Feature]" | File coinvolti, issue, log, stack trace |
| Feature development | "Feature [Nome]" | Spec, wireframe, file da modificare, test esistenti |
| Cross-team collaboration | "Integration [Team A + B]" | API contracts, schema condivisi, documenti di accordo |
| Migration project | "Migration [Legacy → New]" | Codice legacy, nuovo target, mapping, piano di migrazione |
| Code review preparation | "Review [PR #xxx]" | PR, test, documentazione correlata, standard del team |
Best Practice per Spaces
Da Fare
- Crea Spaces specifici per contesto (non uno Space generico per tutto)
- Includi sempre le convenzioni del progetto (file .copilot-instructions.md)
- Aggiorna lo Space quando il progetto evolve
- Aggiungi testo libero per informazioni non presenti nel codice
- Condividi gli Spaces con i membri del team
- Includi sia il codice che la documentazione correlata
- Usa Spaces diversi per fasi diverse (development, debug, review)
Da Evitare
- Non includere troppi repository irrilevanti (rumore nel contesto)
- Non creare uno Space unico per tutto il lavoro
- Non dimenticare di aggiornare lo Space dopo cambiamenti significativi
- Non includere file binari o asset di grandi dimensioni
- Non trascurare il testo libero: spesso e' il contesto più' prezioso
- Non condividere Spaces con contenuti sensibili senza verificare i permessi
- Non sovraccaricare uno Space con decine di issue poco rilevanti
Agentic Memory: Memoria Persistente per Copilot
La Agentic Memory e' una delle funzionalità' più' rivoluzionarie introdotte in Copilot, attualmente disponibile in Early Access per gli utenti dei piani Pro e Pro+. Si tratta di un sistema di memoria persistente che permette a Copilot di ricordare informazioni apprese durante le interazioni precedenti, eliminando la necessità' di ripetere le stesse spiegazioni in ogni nuova sessione di chat.
Come Funziona la Memoria
La Agentic Memory funziona attraverso un processo di deduzione automatica. Durante le conversazioni con Copilot, il sistema identifica informazioni che potrebbero essere utili in futuro e le salva come "memorie". Queste memorie non sono copie esatte delle conversazioni, ma sintesi strutturate delle informazioni chiave dedotte dall'interazione.
Ciclo di Vita di una Memoria
- Deduzione: Durante una conversazione, Copilot identifica informazioni potenzialmente utili
- Creazione: L'informazione viene sintetizzata e salvata come memoria strutturata
- Associazione: La memoria viene associata al repository specifico in cui e' stata creata
- Utilizzo: Nelle conversazioni successive nello stesso repository, la memoria viene utilizzata come contesto
- Validazione: Ogni volta che la memoria viene utilizzata con successo, il suo tempo di vita viene esteso
- Scadenza: Le memorie non utilizzate scadono automaticamente dopo 28 giorni
Tipi di Memorie
Il sistema non memorizza tutto indiscriminatamente. Le memorie vengono categorizzate e filtrate per rilevanza, focalizzandosi su informazioni che hanno un alto valore di riutilizzo.
Categorie di Memorie
| Categoria | Esempi | Valore |
|---|---|---|
| Struttura del progetto | Organizzazione delle cartelle, architettura, moduli principali | Evita di rispiegare come e' organizzato il codice |
| Convenzioni di coding | Stile di naming, pattern utilizzati, regole di linting | Genera codice coerente con gli standard del team |
| Pattern ricorrenti | Come si creano nuovi endpoint, come si scrivono test, come si gestiscono errori | Riproduce pattern approvati senza richiedere istruzioni |
| Decisioni tecniche | perchè' si usa una libreria specifica, trade-off architetturali | Suggerisce soluzioni allineate con le scelte del team |
| Informazioni di dominio | Regole di business, terminologia specifica, vincoli normativi | Comprende il dominio senza spiegazioni ripetute |
| Preferenze personali | Stile di commento, livello di dettaglio, formato delle risposte | Personalizza le risposte in base alle preferenze |
Persistenza e Scadenza
Le memorie hanno un ciclo di vita ben definito, progettato per bilanciare utilita' e rilevanza nel tempo.
Regole di Persistenza
| Regola | Dettaglio |
|---|---|
| Durata iniziale | 28 giorni dalla creazione |
| Rinnovo | Ogni utilizzo resetta il timer di 28 giorni |
| Scadenza | Auto-eliminazione dopo 28 giorni di inattivita' |
| Scope | Memorie specifiche per repository (non globali) |
| Compattazione | Al 95% del limite token, le memorie meno rilevanti vengono compattate |
| Privacy | Le memorie non vengono condivise tra utenti o repository |
| Cancellazione | L'utente può' cancellare manualmente qualsiasi memoria |
| Visibilità' | L'utente può' visualizzare tutte le memorie attive |
Scope Repository-Specific
Un aspetto fondamentale della Agentic Memory e' che le memorie sono specifiche per repository. Le informazioni apprese lavorando sul repository A non vengono utilizzate quando lavori sul repository B. Questo design garantisce che il contesto sia sempre pertinente e previene contaminazioni tra progetti diversi.
Questa scelta progettuale ha implicazioni importanti: le convenzioni del progetto A non influenzeranno i suggerimenti per il progetto B, anche se usi lo stesso account Copilot. Ogni repository ha il suo "cervello" indipendente, che cresce e si arricchisce solo con le interazioni specifiche per quel repository.
Implicazioni dello Scope per Repository
- Monorepo: In un monorepo, tutte le memorie sono condivise tra i moduli (attenzione alle convenzioni diverse tra moduli)
- Fork: I fork sono repository separati, quindi le memorie non vengono trasferite
- Rename: Il rename del repository preserva le memorie (l'ID interno rimane lo stesso)
- Multi-repo: Devi costruire memorie separate per ogni repository, anche se fanno parte dello stesso progetto
- Transfer: Il trasferimento di un repository a un'altra organizzazione preserva le memorie
Auto-Compattazione
Quando il volume delle memorie raggiunge il 95% del limite massimo di token allocato, il sistema attiva un processo di auto-compattazione. Le memorie vengono valutate in base a frequenza di utilizzo, recenza e rilevanza. Le memorie meno utilizzate vengono condensate o rimosse per fare spazio a nuove informazioni.
Questo meccanismo garantisce che il "cervello" di Copilot per ogni repository rimanga focalizzato sulle informazioni più' utili, senza accumulare detriti informativi che potrebbero degradare la qualità' delle risposte. E' un processo automatico che non richiede intervento dell'utente, anche se e' possibile gestire manualmente le memorie se necessario.
Vantaggi Pratici della Agentic Memory
Prima e Dopo la Agentic Memory
| Scenario | Senza Memory | Con Memory |
|---|---|---|
| Nuova sessione di chat | Devi rispiegare struttura del progetto e convenzioni | Copilot sa gia' come e' organizzato il progetto |
| Creazione nuovo endpoint | Devi specificare pattern, middleware, validazione | Copilot riproduce il pattern degli endpoint esistenti |
| Risoluzione bug | Devi descrivere come funziona il sistema coinvolto | Copilot conosce l'architettura e suggerisce dove cercare |
| Code review | Devi spiegare le regole del team | Copilot applica automaticamente le convenzioni del team |
| Refactoring | Devi definire il target architecture | Copilot conosce le preferenze architetturali |
| Testing | Devi specificare framework, stile, coverage target | Copilot genera test coerenti con quelli esistenti |
| Documentazione | Devi indicare formato, stile, convenzioni | Copilot produce docs allineati al resto del progetto |
Gestione Manuale delle Memorie
Nonostante il sistema sia progettato per essere automatico, gli utenti hanno pieno controllo sulle memorie memorizzate. Puoi:
- Visualizzare: Accedere alla lista completa delle memorie per ogni repository
- Modificare: Correggere memorie imprecise o aggiungere dettagli
- Eliminare: Rimuovere memorie obsolete o errate
- Forzare la creazione: Puoi esplicitamente chiedere a Copilot di ricordare qualcosa
// Nella chat di Copilot, puoi dire:
"Ricorda che in questo progetto usiamo sempre
il pattern Result<T, E> per la gestione degli errori
invece di lanciare eccezioni. Ogni servizio deve
restituire Result<SuccessType, ErrorType>."
"Ricorda che le migrazioni del database vanno sempre
create con il comando: npx prisma migrate dev --name <nome-descrittivo>"
"Ricorda che il nostro naming convention per i branch e':
feature/JIRA-XXX-breve-descrizione
fix/JIRA-XXX-breve-descrizione
chore/JIRA-XXX-breve-descrizione"
"Ricorda che i test di integrazione devono usare
il database di test (TEST_DATABASE_URL) e non il
database di sviluppo."Repository Indexing: Ricerca Semantica Istantanea
Il Repository Indexing e' il motore che alimenta la comprensione profonda del codice da parte di Copilot. Quando un repository viene indicizzato, Copilot crea una rappresentazione semantica del codice che gli permette di comprendere non solo la struttura dei file, ma anche le relazioni logiche tra componenti, le dipendenze tra moduli e il flusso dei dati attraverso il sistema.
Indicizzazione Automatica
L'indicizzazione avviene automaticamente la prima volta che un utente avvia una conversazione Copilot Chat in un repository. Non e' necessaria alcuna configurazione o azione manuale. Una volta completata l'indicizzazione, tutti gli utenti Copilot che accedono a quel repository beneficiano dell'indice condiviso.
Dettagli dell'Indicizzazione
| Aspetto | Dettaglio |
|---|---|
| Trigger | Automatico alla prima conversazione Copilot nel repository |
| Velocita' | Sotto i 60 secondi per la maggior parte dei repository |
| Aggiornamento | Incrementale ad ogni push (solo file modificati) |
| Condivisione | L'indice e' condiviso tra tutti gli utenti Copilot del repository |
| Privacy | L'indice non viene usato per addestrare modelli AI |
| Dimensione | Supporta repository fino a milioni di righe di codice |
| Linguaggi | Tutti i linguaggi supportati da GitHub |
| Branch | L'indicizzazione copre il branch di default (main/master) |
Cosa Viene Indicizzato
L'indicizzazione va ben oltre un semplice indice di ricerca testuale. Il sistema crea una comprensione semantica del codice che include:
Livelli di Indicizzazione
| Livello | Cosa Analizza | Beneficio |
|---|---|---|
| Struttura file | Organizzazione cartelle, naming convention, pattern di progetto | Copilot comprende dove cercare ciascun tipo di risorsa |
| Definizioni | Classi, interfacce, funzioni, tipi, costanti | Suggerimenti precisi per tipi e firme di metodo |
| Relazioni | Import/export, ereditarieta', composizione, dipendenze | Comprende l'impatto delle modifiche su altri file |
| Pattern | Pattern architetturali ricorrenti, convenzioni di coding | Genera codice coerente con i pattern esistenti |
| Logica | Flusso dei dati, gestione errori, trasformazioni | Suggerisce implementazioni che si integrano con la logica esistente |
| Documentazione | Commenti, JSDoc, README, markdown | Utilizza la documentazione per comprendere l'intento del codice |
| Test | Test case, assertion, mock, fixture | Genera test coerenti con la strategia di testing del progetto |
| Configurazione | Config file, environment, build settings | Comprende l'ambiente e le dipendenze del progetto |
Velocita' di Indicizzazione
Una delle innovazioni più' significative e' la riduzione del tempo di indicizzazione a meno di 60 secondi. Nelle versioni precedenti, l'indicizzazione poteva richiedere minuti o anche ore per repository di grandi dimensioni. Oggi, grazie a ottimizzazioni nell'algoritmo di embedding e nell'infrastruttura di indicizzazione, la ricerca semantica e' disponibile quasi istantaneamente.
Dopo l'indicizzazione iniziale, gli aggiornamenti sono incrementali: quando fai push di nuovi commit, solo i file modificati vengono re-indicizzati, mantenendo l'indice sempre aggiornato senza richiedere una re-indicizzazione completa.
Impatto sulla qualità' delle Risposte
Il Repository Indexing ha un impatto diretto e misurabile sulla qualità' delle risposte di Copilot. Senza indicizzazione, Copilot può' vedere solo i file attualmente aperti nell'editor. Con l'indicizzazione, ha accesso all'intera base di codice.
Esempio di Impatto
| Domanda | Senza Indicizzazione | Con Indicizzazione |
|---|---|---|
| "Come gestisce il progetto l'autenticazione?" | Risposta generica basata su best practice | Risposta specifica che descrive il middleware JWT, il servizio auth e i guard |
| "Crea un nuovo endpoint per i pagamenti" | Endpoint generico senza contesto | Endpoint che segue i pattern del progetto, con middleware, validazione e errori coerenti |
| "perchè' il test X fallisce?" | Analisi limitata al file del test | Analisi che include il servizio sotto test, le dipendenze e i mock necessari |
| "Quali file devo modificare per aggiungere un campo al modello User?" | Solo il file del modello | Modello, migration, DTO, validazione, serializer, test, docs |
Enterprise Controls
Per le organizzazioni, il Repository Indexing offre controlli granulari per gestire quali contenuti vengono indicizzati e quali esclusi. Questo e' particolarmente importante per repository che contengono codice sensibile o informazioni proprietarie.
# File e cartelle da escludere dall'indicizzazione Copilot
# Simile a .gitignore ma specifico per Copilot
# Secrets e credenziali
.env
.env.*
**/secrets/
**/credentials/
**/*.pem
**/*.key
# Dati sensibili
**/fixtures/customers.json
**/seed/production-data.sql
# Codice proprietario
src/core/proprietary-algorithm/
src/core/patent-pending/
# File generati (rumore nell'indicizzazione)
dist/
build/
node_modules/
coverage/
*.min.js
*.bundle.js
# Vendor code
vendor/
third-party/
# File di grandi dimensioni (non utili per il contesto)
**/*.csv
**/*.sql.gz
**/*.dumpSinergia tra Spaces, Memory e Indexing
La vera potenza di questi tre strumenti emerge quando lavorano insieme. Ciascuno copre un aspetto diverso del problema del contesto, e insieme forniscono a Copilot una comprensione completa e persistente del progetto.
Come Collaborano i Tre Sistemi
| Strumento | Tipo di Contesto | Persistenza | Scope |
|---|---|---|---|
| Repository Indexing | Struttura e relazioni del codice | Permanente (aggiornamento incrementale) | Intero repository |
| Copilot Spaces | Contesto multi-sorgente curato dall'utente | Persistente (gestito dall'utente) | Multi-repository |
| Agentic Memory | Conoscenza dedotta dalle interazioni | 28 giorni (rinnovabile) | Repository specifico |
In pratica, quando fai una domanda a Copilot:
- Repository Indexing recupera i file e le strutture di codice rilevanti
- Spaces aggiunge il contesto aggiuntivo (issue, PR, documentazione, note)
- Agentic Memory applica le convenzioni e le preferenze apprese nelle sessioni precedenti
- Tutti questi contesti vengono combinati e inviati al modello per generare la risposta
Esempi Pratici
Vediamo come questi strumenti si applicano in scenari di lavoro quotidiano.
Esempio 1: Setup Space per Progetto Multi-Repo
PROGETTO: E-commerce platform con 5 microservizi
REPOSITORY:
1. ecommerce-gateway (API Gateway - Node.js)
2. ecommerce-products (Catalogo prodotti - Python/FastAPI)
3. ecommerce-orders (Gestione ordini - Java/Spring Boot)
4. ecommerce-payments (Pagamenti - Go)
5. ecommerce-notifications (Notifiche - Node.js)
SPACE CONSIGLIATO: "E-commerce Platform"
CONTENUTI:
- Tutti i 5 repository
- File proto/ con le definizioni gRPC condivise
- File di OpenAPI di ogni servizio
- Documento di architettura (C4 model)
- ADR (Architecture Decision Records)
- Note sul team: "Il team payments e' esterno,
comunicazione via Slack #payments-integration"
RISULTATO:
Quando chiedi "Come funziona il flusso di checkout?",
Copilot può' tracciare il flusso attraverso tutti i servizi:
Gateway -> Products (verifica disponibilità')
-> Orders (crea ordine)
-> Payments (processa pagamento)
-> Notifications (invia conferma)Esempio 2: Utilizzo della Memory per Convenzioni
SESSIONE 1 (Giorno 1):
Developer: "Crea un nuovo servizio per la gestione delle fatture"
Copilot genera il servizio seguendo pattern generici.
Developer: "No, nel nostro progetto i servizi seguono sempre
questo pattern: InvoiceService extends BaseService<Invoice>
con i metodi findById, findAll, create, update, delete.
Usiamo anche il decorator @Injectable() e il pattern
Result<T, E> per gli errori."
Copilot genera la versione corretta.
>> MEMORIA CREATA: "I servizi seguono il pattern
BaseService<T> con decorator @Injectable() e Result<T,E>"
SESSIONE 2 (Giorno 5):
Developer: "Crea un servizio per gestire i clienti"
Copilot genera automaticamente:
- CustomerService extends BaseService<Customer>
- @Injectable() decorator
- Tutti i metodi CRUD con Result<T, E>
- Error handling coerente con InvoiceService
>> NESSUNA ISTRUZIONE AGGIUNTIVA NECESSARIAEsempio 3: Repository Indexing per Code Exploration
CONTESTO: Nuovo sviluppatore sul progetto (50K righe di codice)
DOMANDE E RISPOSTE (con Repository Indexing):
D: "Come e' strutturato il progetto?"
R: Il progetto segue una Clean Architecture con 4 layer:
- src/domain/ (entità' e business rules)
- src/application/ (use cases)
- src/infrastructure/ (database, API esterne)
- src/presentation/ (controller, DTO, middleware)
[cita file e cartelle specifiche]
D: "Come funziona l'autenticazione?"
R: L'autenticazione usa JWT con refresh token:
- src/infrastructure/auth/jwt.strategy.ts (validazione)
- src/infrastructure/auth/auth.guard.ts (protezione route)
- src/application/auth/auth.service.ts (logica di login)
[mostra il flusso con riferimenti al codice reale]
D: "Dove devo mettere un nuovo endpoint per i report?"
R: Basandomi sulla struttura del progetto:
- Controller: src/presentation/controllers/report.controller.ts
- Service: src/application/services/report.service.ts
- Repository: src/infrastructure/repositories/report.repository.ts
- DTO: src/presentation/dto/report.dto.ts
- Test: test/unit/report.service.spec.ts
[segue esattamente il pattern degli altri endpoint]Configurazione Avanzata
Per sfruttare al massimo questi strumenti, e' importante configurarli correttamente in base alle esigenze del progetto e del team.
File .copilot-instructions.md
Il file .copilot-instructions.md nella root del repository viene
automaticamente incluso nel contesto di ogni conversazione Copilot. E' il modo più'
diretto per fornire istruzioni persistenti a Copilot per un repository specifico.
# Istruzioni per Copilot
## Stack Tecnologico
- Backend: NestJS 10 con TypeScript 5.3
- Database: PostgreSQL 16 con Prisma 5
- Cache: Redis 7
- Queue: BullMQ
- Testing: Jest + Supertest
- Linting: ESLint + Prettier
## Convenzioni di Coding
### Naming
- File: kebab-case (user.service.ts)
- Classi: PascalCase (UserService)
- Metodi: camelCase (findById)
- Costanti: UPPER_SNAKE_CASE (MAX_RETRY_COUNT)
- Interfacce: PascalCase con prefisso I (IUserRepository) -- NO, senza prefisso
### Pattern
- Servizi: estendono BaseService<T>
- Repository: implementano IRepository<T>
- Controller: usano @Controller() decorator con path plurale (/users, /orders)
- DTO: usano class-validator per validazione
- Errori: Result<T, AppError> pattern (mai throw eccezioni)
### Testing
- Unit test: file.spec.ts nella stessa cartella del sorgente
- Integration test: test/integration/ con database di test
- E2E test: test/e2e/ con supertest
- Coverage target: 80% per servizi, 60% per controller
### Git
- Branch: feature/PROJ-XXX-descrizione, fix/PROJ-XXX-descrizione
- Commit: conventional commits (feat:, fix:, chore:, docs:)
- PR: template in .github/PULL_REQUEST_TEMPLATE.md
## Regole di Business
- I prezzi sono sempre in centesimi (integer, mai float)
- Le date sono sempre in UTC
- Gli ID sono UUID v4
- Soft delete per tutte le entità' (campo deletedAt)
- Audit trail per ogni operazione CRUD (campo createdBy, updatedBy)Ottimizzare l'Indicizzazione
Per migliorare la qualità' dell'indicizzazione e le performance della ricerca semantica, segui queste linee guida:
Migliora la qualità'
- Mantieni una struttura di cartelle chiara e consistente
- Usa JSDoc/TSDoc per documentare funzioni e classi
- Scrivi commenti significativi per logica complessa
- Mantieni README aggiornati per ogni modulo
- Usa nomi descrittivi per file, classi e funzioni
- Documenta le relazioni tra moduli nei file README
Riduci il Rumore
- Escludi file generati con .copilotignore
- Escludi dipendenze vendored non necessarie
- Escludi file di dati di grandi dimensioni (CSV, dump)
- Escludi codice legacy non più' utilizzato
- Escludi file di lock (package-lock.json e' utile, yarn.lock meno)
- Escludi asset binari (immagini, font, video)
Confronto con Approcci Alternativi
Per contestualizzare Spaces, Memory e Indexing, e' utile confrontarli con approcci alternativi per fornire contesto all'AI.
Confronto Approcci al Contesto
| Approccio | Pro | Contro | Quando Usarlo |
|---|---|---|---|
| File aperti nell'editor | Semplice, immediato | Contesto limitato ai file aperti | Modifiche locali a pochi file |
| #file mentions in chat | Controllo preciso | Manuale, richiede conoscenza dei file | Domande su file specifici |
| Repository Indexing | Automatico, completo | Solo codice del repository | Sempre (attivo di default) |
| Copilot Spaces | Multi-repo, multi-formato | Richiede setup iniziale | Progetti complessi, multi-repo |
| Agentic Memory | Automatico, persistente | Limitato a 28 giorni, per repo | Convenzioni ricorrenti, pattern |
| .copilot-instructions.md | Persistente, condiviso col team | Solo testo, non dinamico | Regole e convenzioni del progetto |
| Prompt manuale dettagliato | Massimo controllo | Non persistente, ripetitivo | Task specifici e complessi |
Limitazioni e Considerazioni
Nonostante i vantaggi evidenti, e' importante conoscere le limitazioni attuali di questi strumenti per utilizzarli con aspettative realistiche.
Limitazioni Attuali
| Strumento | Limitazione | Impatto | Mitigazione |
|---|---|---|---|
| Spaces | Non supporta aggiornamento automatico dei contenuti | Rischio di contesto obsoleto | Review periodica dello Space |
| Spaces | Limite al numero di repository per Space | Progetti molto distribuiti possono non stare in un solo Space | Creare Spaces tematici più' piccoli |
| Memory | Scadenza a 28 giorni per memorie non utilizzate | Conoscenza persa se non riutilizzata | Usare .copilot-instructions.md per info permanenti |
| Memory | Scope limitato a singolo repository | Non trasferisce conoscenza tra repo dello stesso progetto | Usare Spaces per contesto cross-repo |
| Memory | Disponibile solo su piani Pro e Pro+ | Non accessibile per piani Free e Business base | Usare file di istruzioni come alternativa |
| Indexing | Solo branch di default indicizzato | Branch feature non beneficiano di indicizzazione | Merge frequenti nel branch principale |
| Indexing | File esclusi da .gitignore non indicizzati | Configurazioni locali non nel contesto | Includere file di esempio nella repository |
| Tutti | Dipendono dalla qualità' del codice e della documentazione | Repository mal documentati beneficiano meno | Investire in documentazione e commenti |
Privacy e Sicurezza dei Dati
Un aspetto importante da considerare, specialmente per team enterprise, riguarda la privacy e la sicurezza dei dati utilizzati da questi strumenti.
Garanzie di Privacy
- Nessun training: I dati di Spaces, Memory e Indexing non vengono utilizzati per addestrare modelli AI
- Isolamento: Le memorie sono isolate per utente e per repository
- Crittografia: I dati sono crittografati in transito e a riposo
- Controllo utente: L'utente può' eliminare tutte le memorie e i dati in qualsiasi momento
- Content exclusion: L'organizzazione può' escludere file e repository dall'indicizzazione
- Compliance: I dati sono trattati in conformità' con i termini di servizio GitHub
- Residenza dati: Per piani Enterprise, i dati possono essere localizzati in regioni specifiche
Conclusione
Copilot Spaces, Agentic Memory e Repository Indexing rappresentano un salto qualitativo nel modo in cui forniamo contesto agli strumenti AI di sviluppo. Invece di ripetere le stesse informazioni ad ogni sessione, possiamo costruire un ecosistema di contesto persistente che cresce e si arricchisce nel tempo.
La combinazione di questi tre strumenti copre tutti gli aspetti del contesto: il codice (Repository Indexing), le informazioni esterne (Spaces) e la conoscenza implicita (Memory). Insieme, trasformano Copilot da un assistente generico a un partner che conosce il tuo progetto, le tue convenzioni e le tue preferenze.
Il consiglio pratico e': inizia con il Repository Indexing (automatico), aggiungi un
file .copilot-instructions.md con le convenzioni del progetto, e poi crea
Spaces per i contesti più' complessi. La Memory si costruira' naturalmente nel tempo
attraverso le tue interazioni quotidiane.
Progresso della Serie
| # | Articolo | Stato |
|---|---|---|
| 1 | Foundation e Mindset | Completato |
| 2 | Ideazione e Requisiti | Completato |
| 3 | Architettura Backend | Completato |
| 4 | Struttura Frontend | Completato |
| 5 | Prompt Engineering | Completato |
| 6 | Testing e qualità' | Completato |
| 7 | Documentazione | Completato |
| 8 | Deploy e DevOps | Completato |
| 9 | Evoluzione e Manutenzione | Completato |
| 10 | Coding Agent | Completato |
| 11 | Code Review | Completato |
| 12 | Copilot Edits | Completato |
| 13 | GitHub Spark | Completato |
| 14 | Spaces e Memory | Sei qui |
| 15 | Modelli AI in Copilot | Prossimo |
| 16 | Personalizzazione | Prossimo |
| 17 | Enterprise | Prossimo |
| 18 | Extensions | Prossimo |
| 19 | Sicurezza e Compliance | Prossimo |