Cockpit by RiftSeed: cosa fa e cosa non fa ancora
· 5 min di lettura · cockpit, mcp, protocollo, agentic-engineering
Il prototipo dove gli agenti di codice ricevono il lavoro e lasciano le prove: il protocollo passo per passo, la mappa, il cancello con i tetti tenuti dal server, gli incidenti, il Commander, e i limiti di oggi.
Il 9 ottobre 2026 sono state contate le richieste che gli agenti avevano registrato in Cockpit by RiftSeed. Erano 82: 62 erano diventate nuovi requisiti proposti, e 10 erano state collegate a un requisito che esisteva già. L’agente decideva senza vedere l’elenco dei requisiti, e una richiesta già coperta tornava come requisito nuovo. Delle dieci richieste collegate a mano, metà erano risposte dentro una conversazione, come «Sì alla 1a», che lette da sole non dicono niente.
Da quel conteggio è nato req.match. Prima di registrare una richiesta, l’agente la riscrive in una frase e chiede a Cockpit se un requisito la dice già. La risposta ordina i candidati per parole in comune, pesate per quanto sono rare nel progetto. Se è acceso un modello decisionale, il modello ne sceglie uno con una probabilità, e la corrispondenza vale solo da 0,8 in su. La chiamata non salva niente.
Il protocollo
Cockpit è un’applicazione web con un server MCP, rs-mcp, che gira come funzione edge su Supabase. Claude Code e Codex si collegano con un token creato nelle impostazioni di Cockpit. I token nuovi cominciano con rsa_ e si possono legare a un solo progetto.
La prima chiamata di ogni sessione è session.start. Restituisce il briefing, con la fase del progetto, le priorità, i requisiti aperti, i test rossi, gli incidenti aperti e le regole di casa, più un briefing_id da passare alle chiamate successive. In questo repository la fa un hook di Claude Code, all’apertura della sessione.
Per ogni richiesta della persona l’agente passa da req.match e poi da request.log, con le parole della persona così come sono. La richiesta si collega a un requisito esistente o ne propone uno nuovo. Un requisito proposto resta tale finché una persona non lo conferma in Cockpit. Gli agenti, Commander compreso, possono solo proporre.
Prima di toccare il codice l’agente chiede impact.get, con una chiave di requisito o con dei percorsi. La risposta elenca i file e i moduli coinvolti, i test da lanciare con la ragione di ciascuno, sonde di interfaccia comprese, l’ultimo giro del cancello, le decisioni e gli incidenti collegati. I test si lanciano in locale o con tests.run, che li fa girare sulle GitHub Actions del progetto, e tests.results riporta gli esiti, prima i falliti.
A fine sessione session.log registra il briefing, i requisiti toccati, i commit, i file cambiati e i test eseguiti. Se la sessione ha prodotto commit nuovi e il resoconto manca, l’hook di chiusura ferma una volta la fine del turno e lo chiede.
Le prove arrivano dalla CI
I test che l’agente dice di aver lanciato entrano nello storico come esiti non verificati e non colorano la mappa. La colora solo la CI. Dopo ogni push su main, il workflow cockpit-gate.yml manda a Cockpit l’esito del cancello, la mappa del codice al nuovo commit, le chiavi di requisito trovate nelle righe Refs: dei commit e il risultato di ogni file di test.
La mappa mostra le parti del prodotto colorate dai test che le proteggono, i requisiti citati da un test e quelli scoperti, e i file che nessun requisito spiega. Lì si vede dove manca un test.
Nemmeno le corsie del cancello si fidano della parola dell’agente. Un rilascio della corsia leggera, con il cancello verde e nessun incidente aperto, si approva con un tocco solo. Per entrarci, la modifica deve restare entro 40 righe e 5 file, non toccare percorsi protetti (migration, funzioni edge, workflow, package.json, i test dei cricchetti), non togliere file di test né asserzioni e non alzare tetti. Lo giudica il server, dal diff che restituisce GitHub.
Il cancello e il verdetto
I tetti dei cricchetti stanno sul server, in una tabella che accetta solo righe nuove. Un tetto più basso, riportato dal ramo di rilascio, diventa il nuovo tetto senza chiedere niente a nessuno. Uno più alto rende rosso il cancello: un tetto sale solo con una decisione registrata da una persona, con la sua ragione. Un incidente passa a «risolto» solo con il commit della correzione e il test di guardia, per un vincolo del database.
Il rilascio aspetta il verdetto di una persona. La chiamata verdict.request restituisce la pagina dove si approva o si respinge; per approvare serve un cancello verde, e finché c’è un incidente aperto il tasto per approvare non compare.
Il Commander
Il Commander è un responsabile di programma AI che vive dentro Cockpit. Legge il progetto e assegna compiti. Un agente li legge con commander.inbox, ne prende uno con task.claim e lo lavora su un ramo cockpit/ con la chiave del compito, aprendo una pull request in bozza. Il merge resta alla persona, e la CI non fa mai il deploy di una bozza o di un ramo cockpit/.
Mentre una sessione tiene un compito, una guardia locale, un hook che gira prima di ogni chiamata a uno strumento, nega i merge, wrangler, gli script di deploy, le migration, i file delle credenziali del proprietario e ogni push che non vada sul ramo del compito. Quando la persona scrive nella sessione la guardia si toglie, perché da lì decide la persona.
Cosa non fa ancora
Lo usa una persona sola: c’è l’accesso dell’amministratore, non ancora organizzazioni o squadre. Non c’è un pacchetto da installare, e collegare un altro repository vuol dire copiare a mano il kit degli hook. La guardia locale esiste solo dove gli hook sono installati; su una macchina senza hook non c’è. I livelli di garanzia calcolati dall’evidenza non esistono ancora, e nemmeno la copertura strutturale del codice: oggi la copertura si conta per requisito. Le schermate di Cockpit pubblicate su questo sito vengono da una demo di sviluppo, con un progetto e dati inventati.
A che punto è
Cockpit by RiftSeed è un prototipo in sviluppo, in anteprima privata, e il laboratorio lo usa ogni giorno sui propri progetti. L’accesso anticipato è per chi sviluppa con agenti di codice e vuole provarlo su un progetto suo. Si chiede dalla chat del sito o dalla pagina dei contatti.
Scritto come nasce ogni cosa in questo lab: con l’AI, poi riletto e approvato da una persona.