1. Capisci il diff
- Riesci a spiegare in una frase cosa cambia per l’utente?
- I file modificati sono coerenti con il task?
- Sono comparsi refactor, rinominazioni o configurazioni non richieste?
- Ci sono file generati, database locali o dati personali inclusi per errore?
Prima della checklist: classifica il rischio della modifica
Non tutte le modifiche meritano lo stesso livello di review. Correggere un refuso e cambiare autenticazione non possono avere la stessa procedura. Prima di leggere il diff, classifica impatto e reversibilità: questo decide quanto approfondire test, sicurezza e verifica manuale.
Se il rischio è alto, chiedi una seconda review umana e prepara un rollback prima del merge. Se non sai classificare la modifica, trattala come rischio medio finché non hai chiarito dati coinvolti, utenti interessati e comportamento precedente.
- Rischio basso
- Testo, stile locale o modifica facilmente reversibile senza dati e senza logica applicativa. Serve comunque una verifica visiva o mirata.
- Rischio medio
- Componente, flusso o dipendenza che può creare regressioni circoscritte. Richiede build, test collegati e prova del percorso utente.
- Rischio alto
- Autenticazione, autorizzazioni, pagamenti, dati personali, migrazioni, cancellazioni o infrastruttura. Richiede review indipendente, test dedicati e piano di rollback.
2. Verifica il comportamento
- Il flusso principale funziona dall’inizio alla fine?
- Gli stati vuoto, loading ed errore sono gestiti quando servono?
- Il comportamento corrisponde agli acceptance criteria?
- Le funzionalità vicine continuano a funzionare?
3. Esegui i controlli tecnici disponibili
- Build di produzione.
- Test automatici collegati alla modifica.
- Lint o type check, se configurati.
- Controllo della console del browser.
- Verifica manuale del flusso realmente modificato.
Un pass di review ripetibile, dal diff alla prova finale
Una review utile lascia evidenze. Registra il comando eseguito, il risultato e ciò che non hai potuto controllare. “Sembra funzionare” non distingue una build superata da una semplice lettura del codice.
Adatta i comandi allo stack del progetto: quelli sotto sono segnaposto operativi, non istruzioni universali. Se il repository documenta comandi ufficiali, usa quelli.
1. Scope
Task: [obiettivo]
Non-goal: [cosa non deve cambiare]
2. Diff
File attesi: [lista]
File modificati: [lista reale]
Modifiche inattese: [nessuna / elenco]
3. Controlli automatici
Build: [comando] -> [esito]
Test mirati: [comando] -> [esito]
Lint/type check: [comando] -> [esito]
4. Verifica manuale
Percorso provato: [passaggi]
Viewport/stato: [desktop, mobile, errore, vuoto]
Esito: [risultato osservato]
5. Non verificato
[limiti, ambiente mancante, casi residui]
6. Decisione
[accetta / correggi / richiedi seconda review]4. Controlla la UI reale
- Desktop e almeno una larghezza mobile.
- Testi lunghi, errori e contenuti vuoti.
- Navigazione con tastiera e focus visibile.
- Contrasto, etichette e messaggi comprensibili.
- Assenza di overflow, sovrapposizioni e controlli irraggiungibili.
5. Cerca rischi di sicurezza e privacy
- Nessuna API key, password o connection string nel frontend o nel diff.
- Gli input non vengono inseriti direttamente in HTML o comandi pericolosi.
- Autorizzazioni e controlli non sono affidati soltanto all’interfaccia.
- Log ed errori non espongono dati sensibili.
- File locali e configurazioni private restano fuori da Git.
6. Valuta nuove dipendenze
- La libreria risolve un problema reale che il progetto non gestisce già?
- È mantenuta e compatibile con lo stack?
- Quanto aggiunge al bundle e alla superficie di rischio?
- È stata aggiunta solo perché l’agente la conosceva meglio?
Prompt copiabile per la review finale
Fai una review finale delle modifiche locali.
Controlla in questo ordine:
1. Bug e regressioni rispetto al task.
2. Modifiche fuori scope.
3. Segreti, dati sensibili e configurazioni locali.
4. Stati errore, vuoto e loading.
5. Responsività, accessibilità e testi lunghi.
6. Dipendenze nuove o non necessarie.
7. Test e verifiche mancanti.
Riporta:
- finding ordinati per gravità
- file e righe coinvolte
- controlli eseguiti davvero
- rischi residui
Non dichiarare eseguito un test che non hai potuto lanciare.Come scrivere un finding che si possa correggere
“Questo codice non mi convince” non aiuta chi deve intervenire. Un finding azionabile collega condizione, comportamento, impatto e posizione. Quando possibile aggiunge il controllo che dimostra il problema.
Ordina i finding per gravità e separali dai suggerimenti di stile. Un bug che espone dati non deve perdersi tra rinominazioni facoltative.
FINDING DEBOLE
La gestione errori è sbagliata.
FINDING AZIONABILE
Condizione:
la richiesta API restituisce 401.
Comportamento osservato:
il componente mantiene visibili i dati caricati dall'utente precedente.
Impatto:
possibile esposizione di dati dopo la scadenza della sessione.
Posizione:
[file e riga]
Verifica:
riprodotto forzando una risposta 401 dopo il caricamento iniziale.
Correzione attesa:
svuotare lo stato sensibile e mostrare il flusso di nuova autenticazione.Fonti e metodo di review
GitHub descrive la pull request review come un passaggio per discutere le modifiche, richiedere correzioni e applicare standard di qualità prima del merge. La guida OWASP aggiunge controlli specifici per sicurezza, dati e segreti. Questa checklist combina i due livelli: correttezza rispetto al task e rischio tecnico.