FR
Le seul personnage de pain du logo CRUMB : une tranche de pain de mie souriante, croquée dans le coin supérieur droit
Retour à la salle

CRUMB

Generative Game Studio · Demo

D’un pitch de jeu en une ligne à une ébauche jouable, avec le travail des agents visible et ouvert à l’intervention.

CRUMB est un harnais de studio multi-agents pour le prototypage de jeux casual.

Conception et développement · réalisé avec des agents de code IA

  • CLIDémo locale
  • Web StudioDémo locale

Les agents qui construisent un jeu, tenus à l’écart des preuves qui le jugent.

Une démo de studio local qui fait passer un pitch de jeu en une ligne par la spécification, le build et les contrôles d’exécution. Chaque étape est consignée dans une transcription JSONL, un reducer pur décide des effets suivants, et seul le dispatcher produit des effets de bord. La QA d’exécution et le verdict du modèle sont tenus séparés pour trancher entre réussite, refonte, réparation et pilotage humain.

On propose un jeu en une ligne et des agents Claude Code, Codex et Gemini CLI collaborent selon Planner → Builder → QA déterministe → Verifier, tandis que CRUMB Studio affiche les événements, l’avancement et les artefacts et accepte des interventions en langage naturel.

Une démo qu’on clone depuis le dépôt public et qu’on exécute en local.

Carte du système · tracée d’après les chemins de code du commit public f5e17c0
Système du studio CRUMBUne personne propose et pilote un jeu depuis Studio, et Studio écrit des commandes dans une inbox. Le coordinateur transmet dans l’ordre au reducer les nouveaux événements de l’inbox et de la transcription ; le reducer pur décide de l’état et des effets suivants, et seul le dispatcher produit des effets de bord. La spécification du Planner, le build et les artefacts du Builder, le résultat de la QA d’exécution et le jugement du Verifier deviennent tous des événements de transcription. Le Verifier ne reçoit que des preuves projetées, et le reducer contrôle et corrige son score d’après le résultat de la QA : PASS termine la session, PARTIAL attend une personne, et tout le reste repart en refonte ou en réparation.Pitch de jeu · pilotageUne personne, en localpackages/studioVue des événements · artefactsÉcrire des commandes dans l’inboxsrc/transcripttranscript.jsonl · append-onlysrc/loop/coordinator.tsBoucle d’événements · rejeu · tailsrc/reducerÉtat → effets suivantsRoutage du verdictsession doneTerminé · PASS ou raison d’arrêtsrc/dispatcher/live.tsExécuter les effets · lancer les acteursProjection de l’entrée du jugemodel-config · presetActeur → harnais · modèleagent actor · CLIPlanner Lead · spécificationBuilder · écrit le jeuartifacts/Fichiers du jeudispatcher/qa-runner.tsQA d’exécution · contrôlesVerifier actorVerifier · verdict du modèlesrc/validatorAnti-tromperie · correction du scorePersonnes · StudioContrôle des événementsla transcription est la source de l’étatAgents de travail · artefactsVérification · décision1pitch · pilotage2événements user3réduire dans l’ordre4effets5configuration des acteurs6lancer le Planner7spec8lancer le Builder9 fichiers · Builder · écrit le jeu → Fichiers du jeu910enregistrement du build11qa_check12ce qui s’exécute13qa.result1qa.result2preuves seulement3entrée du juge4judge.score5score · preuves de QA6verdict corrigé7terminé1verdict corrigé2contrôle PARTIAL3refonte · réparation4terminé5pitch · pilotage1nouveaux événements · rejeu2réduire dans l’ordre3lecture · SSE

Du pitch au jeu

Un pitch devient une spécification, un build et une exécution de QA. Chaque étape passe par la transcription ; les acteurs ne s’appellent pas entre eux.

  1. Pitch de jeu · pilotagepitch · pilotageÉcrire des commandes dans l’inboxpackages/studio

    Un pitch de jeu en une ligne et un pilotage en langage naturel sont saisis dans Studio, qui écrit des commandes dans l’inbox. Studio ne modifie jamais directement la transcription.

  2. Écrire des commandes dans l’inboxpackages/studioévénements userBoucle d’événements · rejeu · tailsrc/loop/coordinator.ts

    Le coordinateur lit les commandes de l’inbox et les consigne dans la transcription comme événements user.

  3. Boucle d’événements · rejeu · tailsrc/loop/coordinator.tsréduire dans l’ordreÉtat → effets suivantssrc/reducer

    Les événements en direct passent un par un d’une file au reducer, ce qui garde l’ordre des effets de chaque événement ; le dispatch lui-même s’exécute de façon asynchrone.

  4. État → effets suivantssrc/reducereffetsExécuter les effets · lancer les acteurssrc/dispatcher/live.ts

    Le reducer est une fonction pure qui ne décide que de l’état et des effets suivants : un goal sélectionne le Planner, une spec le Builder, un build un qa_check.

  5. Acteur → harnais · modèlemodel-config · presetconfiguration des acteurssrc/dispatcher/live.ts

    Le harnais, le fournisseur et le modèle qui exécutent un acteur sont résolus dans l’ordre flag CLI > config > preset > ambient > fallback. Un acteur n’est pas un fournisseur fixe.

  6. Exécuter les effets · lancer les acteurssrc/dispatcher/live.tslancer le PlannerPlanner Lead · spécificationagent actor · CLI

    Le dispatcher lance le Planner avec une entrée projetée. La recherche conditionnelle se poursuit par le plan de recherche du Planner et la passation des preuves, repliés sur cette carte.

  7. Planner Lead · spécificationagent actor · CLIspectranscript.jsonl · append-onlysrc/transcript

    La spécification du Planner devient un événement de transcription, et le reducer en déduit le Builder. Les acteurs ne s’appellent pas entre eux.

  8. Exécuter les effets · lancer les acteurssrc/dispatcher/live.tslancer le BuilderBuilder · écrit le jeuagent actor · CLI

    Le dispatcher lance le Builder. Si le même acteur échoue à répétition, un circuit s’ouvre et change d’adaptateur, puis s’arrête si les échecs continuent.

  9. Builder · écrit le jeuagent actor · CLIfichiersFichiers du jeuartifacts/

    Le Builder écrit le fichier d’entrée, les sources et les assets comme artefacts.

  10. Builder · écrit le jeuagent actor · CLIenregistrement du buildtranscript.jsonl · append-onlysrc/transcript

    L’événement build et artifact.created sont consignés dans la transcription avec l’identité de l’artefact.

  11. Exécuter les effets · lancer les acteurssrc/dispatcher/live.tsqa_checkQA d’exécution · contrôlesdispatcher/qa-runner.ts

    Après un événement build, le reducer émet un effet qa_check portant l’identité de l’artefact et du build ainsi que les conditions d’acceptation, et le dispatcher l’exécute.

  12. Fichiers du jeuartifacts/ce qui s’exécuteQA d’exécution · contrôlesdispatcher/qa-runner.ts

    La QA d’exécution lance l’artefact réel avec des contrôles par code et dans le navigateur. Le délai par défaut de 120 secondes est une valeur de configuration.

  13. QA d’exécution · contrôlesdispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    Succès ou échec, le résultat est consigné comme événement système qa.result. Même si le contrôle lève une exception, un résultat avec les champs en échec est consigné.

Frontière de confiance de la vérification

La QA d’exécution est une preuve issue de l’exécution réelle de l’artefact ; le Verifier est un modèle qui juge des preuves projetées. Le reducer concilie les deux avant de choisir la suite.

  1. QA d’exécution · contrôlesdispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    Succès ou échec, le résultat est consigné comme événement système qa.result. Même si le contrôle lève une exception, un résultat avec les champs en échec est consigné.

  2. transcript.jsonl · append-onlysrc/transcriptpreuves seulementProjection de l’entrée du jugesrc/dispatcher/live.ts

    L’entrée du Verifier est projetée à partir des derniers goal, spec, build, qa.result et artifact.created, plus une sélection de preuves de recherche. Cela restreint le contexte ; cela ne prouve ni l’isolation ni l’absence de fuite.

  3. Projection de l’entrée du jugesrc/dispatcher/live.tsentrée du jugeVerifier · verdict du modèleVerifier actor

    Le dispatcher lance le Verifier avec l’entrée projetée.

  4. Verifier · verdict du modèleVerifier actorjudge.scoretranscript.jsonl · append-onlysrc/transcript

    Le verdict du Verifier est consigné comme événement judge.score. C’est le jugement d’un modèle, pas un fait d’exécution.

  5. État → effets suivantssrc/reducerscore · preuves de QAAnti-tromperie · correction du scoresrc/validator

    Sur judge.score, le reducer le transmet au contrôle anti-tromperie avec le résultat de la QA, le fournisseur du Builder et le plan et les preuves de recherche.

  6. Anti-tromperie · correction du scoresrc/validatorverdict corrigéRoutage du verdictsrc/reducer

    Un PASS sans exécution réussie devient FAIL, et le score lié à l’exécution est corrigé d’après la QA déterministe. Les autres règles sont des corrections conditionnelles, pas une preuve générale de véracité.

  7. Routage du verdictsrc/reducerterminéTerminé · PASS ou raison d’arrêtsession done

    PASS termine la session comme done. Les arrêts sur budget ou sur circuit se terminent aussi en done mais gardent leur raison d’arrêt ; done n’est donc pas toujours PASS.

Échec et pilotage humain

PARTIAL va à une personne, Critical à la refonte, Important ou Minor à la réparation, et les arrêts sur budget ou circuit laissent une raison d’arrêt.

  1. Anti-tromperie · correction du scoresrc/validatorverdict corrigéRoutage du verdictsrc/reducer

    Un PASS sans exécution réussie devient FAIL, et le score lié à l’exécution est corrigé d’après la QA déterministe. Les autres règles sont des corrections conditionnelles, pas une preuve générale de véracité.

  2. Routage du verdictsrc/reducercontrôle PARTIALPitch de jeu · pilotage

    PARTIAL attend qu’une personne vérifie.

  3. Routage du verdictsrc/reducerrefonte · réparationsrc/dispatcher/live.ts

    Parmi FAIL et REJECT, Critical repart vers le Planner pour une refonte, et Important ou Minor vers le Builder comme retour de correction, tous exécutés comme effets du dispatcher.

  4. Routage du verdictsrc/reducerterminéTerminé · PASS ou raison d’arrêtsession done

    PASS termine la session comme done. Les arrêts sur budget ou sur circuit se terminent aussi en done mais gardent leur raison d’arrêt ; done n’est donc pas toujours PASS.

  5. Pitch de jeu · pilotagepitch · pilotageÉcrire des commandes dans l’inboxpackages/studio

    Un pitch de jeu en une ligne et un pilotage en langage naturel sont saisis dans Studio, qui écrit des commandes dans l’inbox. Studio ne modifie jamais directement la transcription.

Rejeu et observation

Reconstruire l’état à partir de la transcription n’exécute aucun effet, et Studio lit le même enregistrement pour l’afficher.

  1. transcript.jsonl · append-onlysrc/transcriptnouveaux événements · rejeuBoucle d’événements · rejeu · tailsrc/loop/coordinator.ts

    Le writer valide le schéma, attribue un ULID et un horodatage, puis ajoute à la suite. Au rejeu, les événements passés ne font que passer par le reducer ; leurs effets ne sont pas réexécutés.

  2. Boucle d’événements · rejeu · tailsrc/loop/coordinator.tsréduire dans l’ordreÉtat → effets suivantssrc/reducer

    Les événements en direct passent un par un d’une file au reducer, ce qui garde l’ordre des effets de chaque événement ; le dispatch lui-même s’exécute de façon asynchrone.

  3. transcript.jsonl · append-onlysrc/transcriptlecture · SSEVue des événements · artefactspackages/studio

    Studio lit la transcription et les artefacts et affiche l’avancement, les métriques et les artefacts via SSE. Ce n’est pas de la télémétrie envoyée à un service distant.

Toutes les connexions avec la même épaisseur. Choisissez un flux pour ne mettre en évidence que son chemin, avec des étapes numérotées.

  • Trait plein · sens des entrées, résultats et enregistrements
  • Tirets · exécution, jugement, requête
  • Pointillés longs · observation et rapport, hors jugement
  • Trait noir épais · le flux sélectionné ; les numéros donnent l’ordre
  • Cadre · frontière de code ou d’état, nommée dans l’en-tête
  • Pastille intérieure · composant de cette frontière
  • Cadre pointillé · hors de cette frontière
  • Contour orange · là où un modèle décide
  • Boucle d’événements · reducer · dispatcher
  • Enregistrements · configuration · artefacts
  • Contrôles déterministes · correction
  • Studio · acteurs

Tracé d’après les chemins de code du commit public f5e17c0. Les acteurs sont des rôles d’exécution, distincts des agents de code qui ont servi à construire ce dépôt.

Source de l’état
La transcription est la source de l’état et le reducer est une fonction pure. Seul le dispatcher produit des effets de bord (lancer les acteurs, la QA, écrire des fichiers) ; le rejeu reconstruit donc l’état sans effets.
Ce que couvre le rejeu
Le rejeu donne le même état ; il ne rend déterministes ni les générations du LLM ni le comportement du navigateur et du réseau.
Ce que couvre un verdict
La QA d’exécution ne vérifie que les contrôles configurés, et le score du Verifier n’est qu’un canal de preuve parmi d’autres. Aucun des deux ne mesure tous les comportements du jeu, son intérêt ou la satisfaction des utilisateurs.