Una pull request che si unisce senza errori può comunque modificare gli obblighi della tua azienda verso un framework: un ruolo ampliato, una riga di log rimossa, un nuovo punto in cui i dati personali vengono memorizzati. Come dichiara Cursor, il compito di Bugbot è segnalare bug probabili e problemi di qualità del codice prima che vengano uniti. Il compito di heygrc è rispondere all'altra domanda: quale controllo è interessato da questa modifica, citando la clausola. Questa guida è la versione pratica per eseguire entrambi, perché nessuno dei due sostituisce l'altro.
A cosa serve ciascuno
Mantieni la divisione dei compiti chiara per il tuo team. Bugbot è un revisore del codice: correttezza, qualità, la modifica stessa. heygrc è un revisore di conformità: analizza la diff rispetto ai framework selezionati (ISO 27001, SOC 2, GDPR e altri) più il contesto aziendale, e quando una modifica interessa un controllo indica quale e perché, come commento di revisione con la clausola allegata. Non facciamo alcuna affermazione su cosa Bugbot segnalerà o tralascerà in una determinata modifica; il punto è che risponde a una domanda diversa.
Configura la coppia
Bugbot viene configurato tramite Cursor, secondo la documentazione ufficiale di Cursor. heygrc è un'app GitHub: installala da github.com/apps/heygrc sui repository che vuoi revisionare (richiede accesso in lettura a codice, metadati e issue, e accesso in scrittura solo a Check e Pull request, mai al codice). Poi configurala tramite codice: una richiesta PUT a api.heygrc.com/v1/config con il profilo aziendale e l'elenco dei framework, che il tuo agente di coding può fare per te in circa tre minuti.
L'ordine non è importante e nessuno dei due strumenti deve sapere dell'esistenza dell'altro. Ciascuno pubblica la propria revisione e il proprio stato di controllo sulla stessa pull request.
Regola il volume prima che qualcuno si irriti
Due bot che commentano su ogni push è il punto in cui i team iniziano a mal tollerare l'idea, quindi decidi la cadenza di heygrc fin dal primo giorno. Offre tre modalità di revisione: auto esegue la revisione su ogni pull request quando viene aperta, riaperta o aggiornata; auto_once esegue la revisione solo all'apertura, non su ogni commit; mention_only rimane silenzioso finché qualcuno non commenta /heygrc sulla PR. Se il tuo team è già abituato al ritmo di un revisore del codice, auto_once è l'inizio a bassa frizione: una lettura di conformità per PR, su richiesta in seguito.
heygrc pubblica anche una revisione consolidata per ogni passaggio, con i risultati in linea raggruppati in un'unica revisione invece che in un commento per ogni risultato, quindi la lente di conformità aggiunge una sola voce al thread, non un flusso.
Decidi cosa blocca un merge
Per impostazione predefinita, heygrc pubblica un controllo neutro: informativo, e la decisione di merge rimane al team. Una volta che ti fidi del segnale, puoi rendere il controllo di conformità obbligatorio tramite la protezione del branch GitHub, allo stesso modo di qualsiasi job CI, quindi una modifica rilevante per un controllo richiede un riconoscimento esplicito umano prima di essere unita. La maggior parte dei team esegue il controllo in modalità informativa per alcune settimane prima; la guida su come rendere la conformità un controllo obbligatorio illustra le impostazioni esatte.
Cosa costa aggiungere la lente
heygrc addebita per revisione, non per utente: gratuito per 25 revisioni al mese su repository privati, poi 19 dollari al mese per organizzazione con 100 revisioni incluse e 0,49 dollari per ogni revisione aggiuntiva, con i repository pubblici sempre gratuiti e una prova illimitata di 14 giorni una volta reclamata l'installazione nella console. Se vuoi confrontare questo con i prezzi pubblicati da ogni strumento di revisione al tuo volume, la pagina di confronto costi esegue i calcoli in base alle tariffe pubblicate dai fornitori.