Cockpit by RiftSeed

In sviluppo. Cockpit è la casa dove si sviluppano i progetti: gli agenti di codice lavorano con un protocollo (briefing di sessione, richieste confrontate con i requisiti, analisi d’impatto, test) e una persona conferma i requisiti e decide ogni rilascio.

Un prototipo in sviluppo, usato ogni giorno sui progetti del laboratorio. Accesso anticipato su richiesta.

Cosa fa oggi

• Una mappa per ogni progetto: Le parti del prodotto colorate dai test che le proteggono, i requisiti citati e quelli scoperti, i file che nessun requisito spiega.
• Richieste e requisiti: Ogni richiesta resta con le parole di chi l’ha fatta e viene confrontata con i requisiti che esistono già, anche con un modello decisionale; il requisito lo conferma una persona.
• Cancello e cricchetti: L’esito della CI a ogni push e i tetti dei cricchetti, tenuti dal server: un tetto sale solo con una decisione registrata.
• Verdetto e incidenti: Un rilascio aspetta il verdetto di una persona, e gli incidenti aperti lo bloccano. Un incidente si chiude solo con il commit della correzione e il test di guardia.
• Lo studio e il Commander: Chi tiene cosa, cosa aspetta una persona. Il Commander, un responsabile di programma AI, assegna compiti che gli agenti lavorano su un ramo a parte, con una pull request in bozza: mai un deploy.
• Il resoconto: Il progetto spiegato a chi non è tecnico: a che punto è, cosa è pronto, cosa manca e chi deve fare cosa.

Il giro di una richiesta

Gli stessi passi dello schema di /method, con quello che li tiene in Cockpit.

1. Richiesta: La richiesta viene registrata con le parole di chi l’ha fatta e confrontata con i requisiti che esistono già.
2. Requisito: Gli agenti propongono requisiti; li conferma solo una persona, in Cockpit.
3. Impatto: Prima di toccare il codice l’agente chiede l’analisi d’impatto: file, moduli e test da lanciare, ciascuno con la sua ragione.
4. Agenti: Ogni sessione parte da un briefing (priorità, requisiti aperti, test rossi) e chiude con commit, file e test registrati.
5. Cancello: Il giro intero dei test a ogni push; i tetti dei cricchetti li tiene il server e possono solo scendere.
6. Persona: Il verdetto sul rilascio lo dà una persona, in Cockpit o nella sessione: nessun agente approva.
7. Rilascio: Ogni rilascio resta con la sua versione, il suo verdetto e le note.
8. Sonde: Un guasto diventa un incidente, che si chiude solo con il test di guardia che lo riproduce.

Con quali agenti

Claude Code e Codex si collegano con un token, attraverso MCP. Un hook apre ogni sessione con il briefing e la chiude chiedendo il resoconto; durante un compito assegnato dal Commander una guardia locale nega deploy, merge e accesso alle credenziali.

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: collegare un altro repository chiede di copiare a mano il kit degli hook.
• I livelli di garanzia calcolati dall’evidenza e la copertura strutturale del codice non esistono ancora; la copertura oggi è per requisito.
• Nessun prezzo e nessuna licenza: è un prototipo.

Accesso anticipato

Per chi sviluppa con agenti di codice e vuole provarlo su un proprio progetto. Si scrive nella chat del sito: nessun prezzo, nessuna data promessa. Contatti

Il metodo · RiftSeed e le piattaforme no-code