IT
Solo il personaggio del pane dal logo di CRUMB: una fetta di pane sorridente con un morso nell’angolo in alto a destra
Torna alla sala

CRUMB

Generative Game Studio · Demo

Da un’idea di gioco in una riga a una bozza giocabile, con il lavoro degli agenti in vista e aperto all’intervento.

CRUMB è un harness da studio multi-agente per la prototipazione di giochi casual.

Progettazione e sviluppo · realizzato con agenti di programmazione IA

  • CLIDemo locale
  • Studio webDemo locale

Gli agenti che costruiscono un gioco, separati dalle prove che lo giudicano.

Una demo di studio locale che porta un’idea di gioco in una riga attraverso specifica, build e controlli di esecuzione. Ogni passo finisce in un transcript JSONL, un reducer puro decide gli effetti successivi, e solo il dispatcher produce effetti collaterali. La QA di esecuzione e il verdetto del modello restano separati per decidere tra superamento, riprogettazione, riparazione e intervento umano.

Si propone un gioco in una riga e gli agenti Claude Code, Codex e Gemini CLI collaborano attraverso Planner → Builder → QA deterministica → Verifier, mentre CRUMB Studio mostra eventi, avanzamento e artefatti e accetta interventi in linguaggio naturale.

Una demo da clonare dal repository pubblico ed eseguire in locale.

Mappa del sistema · disegnata dai percorsi del codice al commit pubblico f5e17c0
Sistema dello studio CRUMBUna persona propone e guida un gioco da Studio, e Studio scrive comandi in una inbox. Il coordinator passa in ordine al reducer i nuovi eventi della inbox e del transcript; il reducer puro decide lo stato e gli effetti successivi, e solo il dispatcher produce effetti collaterali. La specifica del Planner, la build e gli artefatti del Builder, il risultato della QA di esecuzione e il giudizio del Verifier diventano tutti eventi del transcript. Il Verifier riceve solo prove proiettate, e il reducer ne controlla e corregge il punteggio in base al risultato della QA: PASS chiude la sessione, PARTIAL attende una persona, e tutto il resto torna indietro per riprogettazione o riparazione.Idea di gioco · interventoUna persona, in localepackages/studioVista eventi · artefattiScrittura dei comandi nella inboxsrc/transcripttranscript.jsonl · append-onlysrc/loop/coordinator.tsCiclo degli eventi · replay · tailsrc/reducerStato → effetti successiviInstradamento del verdettosession doneConcluso · PASS o motivo di arrestosrc/dispatcher/live.tsEsecuzione degli effetti · avvio degli actorProiezione dell’input del giudicemodel-config · presetActor → harness · modelloagent actor · CLIPlanner Lead · specificaBuilder · scrive il giocoartifacts/File di giocodispatcher/qa-runner.tsQA di esecuzione · controlliVerifier actorVerifier · verdetto del modellosrc/validatorAnti-deception · correzione del punteggioPersone · StudioControllo degli eventiil transcript è l’origine dello statoAgenti al lavoro · artefattiVerifica · decisione1proposta · intervento2eventi user3riduzione in ordine4effetti5configurazione degli actor6esecuzione del Planner7spec8esecuzione del Builder9file10registro della build11qa_check12cosa viene eseguito13qa.result1qa.result2solo prove3input del giudice4judge.score5punteggio · prove della QA6verdetto corretto7concluso1verdetto corretto2verifica PARTIAL3riprogettazione · riparazione4concluso5proposta · intervento1nuovi eventi · replay2riduzione in ordine3lettura · SSE

Dalla proposta al gioco

Una proposta diventa una specifica, una build e un’esecuzione della QA. Ogni passo passa per il transcript; gli actor non si chiamano tra loro.

  1. Idea di gioco · interventoproposta · interventoScrittura dei comandi nella inboxpackages/studio

    Un’idea di gioco in una riga e gli interventi in linguaggio naturale si inseriscono in Studio, che scrive comandi nella inbox. Studio non modifica mai direttamente il transcript.

  2. Scrittura dei comandi nella inboxpackages/studioeventi userCiclo degli eventi · replay · tailsrc/loop/coordinator.ts

    Il coordinator legge i comandi della inbox e li registra nel transcript come eventi user.

  3. Ciclo degli eventi · replay · tailsrc/loop/coordinator.tsriduzione in ordineStato → effetti successivisrc/reducer

    Gli eventi dal vivo vengono ridotti uno alla volta da una coda, mantenendo in ordine gli effetti di ciascun evento; il dispatch in sé gira in modo asincrono.

  4. Stato → effetti successivisrc/reducereffettiEsecuzione degli effetti · avvio degli actorsrc/dispatcher/live.ts

    Il reducer è una funzione pura che decide solo lo stato e gli effetti successivi: un goal seleziona il Planner, una spec il Builder, una build un qa_check.

  5. Actor → harness · modellomodel-config · presetconfigurazione degli actorsrc/dispatcher/live.ts

    Con quale harness, provider e modello viene eseguito un actor si stabilisce nell’ordine flag della CLI > config > preset > ambient > fallback. Un actor non è un provider fisso.

  6. Esecuzione degli effetti · avvio degli actorsrc/dispatcher/live.tsesecuzione del PlannerPlanner Lead · specificaagent actor · CLI

    Il dispatcher esegue il Planner con l’input proiettato. La ricerca condizionale prosegue attraverso il piano di ricerca del Planner e il passaggio delle prove, ripiegati in questa mappa.

  7. Planner Lead · specificaagent actor · CLIspectranscript.jsonl · append-onlysrc/transcript

    La specifica del Planner diventa un evento del transcript, e da essa il reducer seleziona il Builder. Gli actor non si chiamano tra loro.

  8. Esecuzione degli effetti · avvio degli actorsrc/dispatcher/live.tsesecuzione del BuilderBuilder · scrive il giocoagent actor · CLI

    Il dispatcher esegue il Builder. Se lo stesso actor continua a fallire, si apre un circuit che cambia l’adapter, e se i fallimenti continuano si ferma.

  9. Builder · scrive il giocoagent actor · CLIfileFile di giocoartifacts/

    Il Builder scrive il file di ingresso, i sorgenti e gli asset come artefatti.

  10. Builder · scrive il giocoagent actor · CLIregistro della buildtranscript.jsonl · append-onlysrc/transcript

    L’evento build e artifact.created vengono registrati nel transcript con l’identità dell’artefatto.

  11. Esecuzione degli effetti · avvio degli actorsrc/dispatcher/live.tsqa_checkQA di esecuzione · controllidispatcher/qa-runner.ts

    Dopo un evento build, il reducer emette un effetto qa_check con l’identità di artefatto e build e le condizioni di accettazione, e il dispatcher lo esegue.

  12. File di giocoartifacts/cosa viene eseguitoQA di esecuzione · controllidispatcher/qa-runner.ts

    La QA di esecuzione esegue l’artefatto reale con controlli di codice e del browser. Il timeout predefinito di 120 secondi è un valore di configurazione.

  13. QA di esecuzione · controllidispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    Successo o fallimento, il risultato viene registrato come evento system qa.result. Anche se il controllo solleva un’eccezione, si registra un risultato con i campi falliti.

Confine di fiducia della verifica

La QA di esecuzione è una prova ottenuta eseguendo davvero l’artefatto; il Verifier è un modello che giudica prove proiettate. Il reducer concilia le due prima di scegliere il percorso successivo.

  1. QA di esecuzione · controllidispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    Successo o fallimento, il risultato viene registrato come evento system qa.result. Anche se il controllo solleva un’eccezione, si registra un risultato con i campi falliti.

  2. transcript.jsonl · append-onlysrc/transcriptsolo proveProiezione dell’input del giudicesrc/dispatcher/live.ts

    L’input del Verifier è proiettato dagli ultimi goal, spec, build, qa.result e artifact.created più prove di ricerca selezionate. Restringe il contesto; non dimostra isolamento né assenza di fughe.

  3. Proiezione dell’input del giudicesrc/dispatcher/live.tsinput del giudiceVerifier · verdetto del modelloVerifier actor

    Il dispatcher esegue il Verifier con l’input proiettato.

  4. Verifier · verdetto del modelloVerifier actorjudge.scoretranscript.jsonl · append-onlysrc/transcript

    Il verdetto del Verifier viene registrato come evento judge.score. È il giudizio di un modello, non un fatto sull’esecuzione.

  5. Stato → effetti successivisrc/reducerpunteggio · prove della QAAnti-deception · correzione del punteggiosrc/validator

    Alla ricezione di judge.score, il reducer lo passa al controllo anti-deception insieme al risultato della QA, al provider del Builder e al piano e alle prove di ricerca.

  6. Anti-deception · correzione del punteggiosrc/validatorverdetto correttoInstradamento del verdettosrc/reducer

    Un PASS senza un’esecuzione riuscita diventa FAIL, e il punteggio legato all’esecuzione viene corretto in base alla QA deterministica. Le altre regole sono correzioni condizionali, non una prova generale di veridicità.

  7. Instradamento del verdettosrc/reducerconclusoConcluso · PASS o motivo di arrestosession done

    PASS chiude la sessione come done. Anche gli arresti per budget e circuit terminano come done ma conservano il motivo dell’arresto, quindi done non è sempre PASS.

Fallimento e intervento umano

PARTIAL va a una persona, Critical alla riprogettazione, Important o Minor alla riparazione, e gli arresti per budget o circuit lasciano un motivo di arresto.

  1. Anti-deception · correzione del punteggiosrc/validatorverdetto correttoInstradamento del verdettosrc/reducer

    Un PASS senza un’esecuzione riuscita diventa FAIL, e il punteggio legato all’esecuzione viene corretto in base alla QA deterministica. Le altre regole sono correzioni condizionali, non una prova generale di veridicità.

  2. Instradamento del verdettosrc/reducerverifica PARTIALIdea di gioco · intervento

    PARTIAL attende la verifica di una persona.

  3. Instradamento del verdettosrc/reducerriprogettazione · riparazionesrc/dispatcher/live.ts

    Tra FAIL e REJECT, Critical torna al Planner per la riprogettazione e Important o Minor al Builder come feedback di correzione, tutti eseguiti come effetti del dispatcher.

  4. Instradamento del verdettosrc/reducerconclusoConcluso · PASS o motivo di arrestosession done

    PASS chiude la sessione come done. Anche gli arresti per budget e circuit terminano come done ma conservano il motivo dell’arresto, quindi done non è sempre PASS.

  5. Idea di gioco · interventoproposta · interventoScrittura dei comandi nella inboxpackages/studio

    Un’idea di gioco in una riga e gli interventi in linguaggio naturale si inseriscono in Studio, che scrive comandi nella inbox. Studio non modifica mai direttamente il transcript.

Replay e osservazione

La ricostruzione dello stato dal transcript non esegue effetti, e Studio legge lo stesso registro per mostrarlo.

  1. transcript.jsonl · append-onlysrc/transcriptnuovi eventi · replayCiclo degli eventi · replay · tailsrc/loop/coordinator.ts

    Il writer valida lo schema, assegna un ULID e un orario e accoda. Nel replay gli eventi passati vengono solo ridotti; i loro effetti non vengono rieseguiti.

  2. Ciclo degli eventi · replay · tailsrc/loop/coordinator.tsriduzione in ordineStato → effetti successivisrc/reducer

    Gli eventi dal vivo vengono ridotti uno alla volta da una coda, mantenendo in ordine gli effetti di ciascun evento; il dispatch in sé gira in modo asincrono.

  3. transcript.jsonl · append-onlysrc/transcriptlettura · SSEVista eventi · artefattipackages/studio

    Studio legge il transcript e gli artefatti e mostra avanzamento, metriche e artefatti via SSE. Non è telemetria inviata a un servizio remoto.

Tutte le connessioni con lo stesso peso. Scegliendo un flusso se ne evidenzia solo il percorso, con passi numerati.

  • Continua · direzione di input, risultati e registri
  • Tratteggiata · esecuzione, giudizio, richiesta
  • Punti lunghi · osservazione e resoconto, separati dal giudizio
  • Linea nera spessa · il flusso scelto; i numeri danno l’ordine
  • Riquadro · confine di codice o di stato, nominato nell’intestazione
  • Chip interno · un componente di quel confine
  • Riquadro punteggiato · fuori da quel confine
  • Contorno arancione · dove decide un modello
  • Ciclo degli eventi · reducer · dispatcher
  • Registri · configurazione · artefatti
  • Controlli deterministici · correzione
  • Studio · actor

Disegnato dai percorsi del codice al commit pubblico f5e17c0. Gli actor sono ruoli di runtime, distinti dagli agenti di programmazione usati per costruire questo repository.

Origine dello stato
Il transcript è l’origine dello stato e il reducer è una funzione pura. Solo il dispatcher produce effetti collaterali (esecuzione degli actor, QA, scrittura di file), quindi il replay ricostruisce lo stato senza effetti.
Cosa copre il replay
Il replay restituisce lo stesso stato; non rende deterministiche le generazioni dell’LLM né il comportamento del browser e della rete.
Cosa copre un verdetto
La QA di esecuzione verifica solo i controlli configurati, e il punteggio del Verifier è un solo filone di prove. Nessuno dei due misura ogni comportamento del gioco, il divertimento o la soddisfazione degli utenti.