BG
Само персонажът филия от логото на CRUMB: усмихната филия хляб, отхапана от горния десен ъгъл
Обратно в залата

CRUMB

Generative Game Studio · Demo

От идея за игра в един ред до играема чернова, с работата на агентите пред очите и отворена за намеса.

CRUMB е многоагентна студийна рамка за прототипиране на казуални игри.

Дизайн и разработка · създадено с AI агенти за програмиране

  • CLIЛокално демо
  • Уеб StudioЛокално демо

Агентите, които изграждат играта, отделени от доказателствата, по които тя се преценява.

Локално студийно демо, което превежда идея за игра в един ред през спецификация, изграждане и проверки на изпълнението. Всяка стъпка влиза в JSONL стенограма, чист reducer решава следващите ефекти, а странични ефекти изпълнява само dispatcher. QA на изпълнението и вердиктът на модела се държат отделно, за да се реши между успех, преработка на дизайна, поправка и човешко насочване.

При идея за игра в един ред агентите Claude Code, Codex и Gemini CLI си сътрудничат по веригата Planner → Builder → детерминистичен QA → Verifier, а CRUMB Studio показва събитията, напредъка и артефактите и приема намеса на естествен език.

Демо, което се клонира от публичното хранилище и се изпълнява локално.

Системна карта · по пътищата в кода при публичния къмит f5e17c0
Студийната система CRUMBЧовек предлага и насочва игра от Studio, а Studio записва команди в inbox. Координаторът подава поред на reducer новите събития от inbox и стенограмата; чистият reducer решава състоянието и следващите ефекти, а странични ефекти изпълнява само dispatcher. Спецификацията на Planner, изграждането и артефактите на Builder, резултатът от QA на изпълнението и преценката на Verifier стават събития в стенограмата. Verifier получава само проектирани доказателства, а reducer проверява и коригира оценката му спрямо резултата от QA: PASS приключва сесията, PARTIAL чака човек, а всичко останало се връща за преработка на дизайна или поправка.Идея за игра · насочванеЧовек, работещ локалноpackages/studioПреглед на събития · артефактиЗапис на команди в inboxsrc/transcripttranscript.jsonl · append-onlysrc/loop/coordinator.tsЦикъл на събитията · възпроизвеждане · tailsrc/reducerСъстояние → следващи ефектиМаршрутизиране по вердиктsession doneГотово · PASS или причина за спиранеsrc/dispatcher/live.tsИзпълнение на ефекти · стартиране на участнициПроекция на входа за съдиятаmodel-config · presetУчастник → рамка · моделagent actor · CLIPlanner Lead · спецификацияBuilder · пише игратаartifacts/Файлове на игратаdispatcher/qa-runner.tsQA на изпълнението · проверкиVerifier actorVerifier · вердикт на моделаsrc/validatorЗащита от заблуда · корекция на оценкатаХора · StudioУправление на събитиятастенограмата е източникът на състояниетоРаботещи агенти · артефактиПроверка · решение1идея · насочване2потребителски събития3редуциране поред4ефекти5настройка на участника6изпълнение на Planner7spec8изпълнение на Builder9 файлове · Builder · пише играта → Файлове на играта910запис на изграждането11qa_check12какво се изпълнява13qa.result1qa.result2само доказателства3вход за съдията4judge.score5оценка · доказателства от QA6коригиран вердикт7готово1коригиран вердикт2проверка PARTIAL3преработка на дизайна · поправка4готово5идея · насочване1нови събития · възпроизвеждане2редуциране поред3четене · SSE

От идеята до играта

Идеята става спецификация, изграждане и изпълнение на QA. Всяка стъпка минава през стенограмата; участниците не се извикват един друг.

  1. Идея за игра · насочванеидея · насочванеЗапис на команди в inboxpackages/studio

    Идеята за игра в един ред и насочването на естествен език се въвеждат в Studio, който записва команди в inbox. Studio никога не редактира стенограмата директно.

  2. Запис на команди в inboxpackages/studioпотребителски събитияЦикъл на събитията · възпроизвеждане · tailsrc/loop/coordinator.ts

    Координаторът чете командите от inbox и ги записва в стенограмата като потребителски събития.

  3. Цикъл на събитията · възпроизвеждане · tailsrc/loop/coordinator.tsредуциране поредСъстояние → следващи ефектиsrc/reducer

    Събитията в реално време се редуцират едно по едно от опашка, като се запазва редът на ефектите на всяко събитие; самото диспечиране върви асинхронно.

  4. Състояние → следващи ефектиsrc/reducerефектиИзпълнение на ефекти · стартиране на участнициsrc/dispatcher/live.ts

    Reducer е чиста функция, която решава само състоянието и следващите ефекти: goal избира Planner, spec избира Builder, build избира qa_check.

  5. Участник → рамка · моделmodel-config · presetнастройка на участникаsrc/dispatcher/live.ts

    Коя рамка, доставчик и модел изпълняват даден участник, се определя в реда CLI флаг > конфигурация > preset > ambient > fallback. Участникът не е фиксиран доставчик.

  6. Изпълнение на ефекти · стартиране на участнициsrc/dispatcher/live.tsизпълнение на PlannerPlanner Lead · спецификацияagent actor · CLI

    Dispatcher изпълнява Planner с проектиран вход. Условното проучване продължава чрез плана за проучване на Planner и предаването на доказателства, свити на тази карта.

  7. Planner Lead · спецификацияagent actor · CLIspectranscript.jsonl · append-onlysrc/transcript

    Спецификацията на Planner става събитие в стенограмата и reducer избира Builder по нея. Участниците не се извикват един друг.

  8. Изпълнение на ефекти · стартиране на участнициsrc/dispatcher/live.tsизпълнение на BuilderBuilder · пише игратаagent actor · CLI

    Dispatcher изпълнява Builder. Ако един и същ участник продължава да се проваля, се отваря circuit, който сменя адаптера, и процесът спира, ако неуспехите продължат.

  9. Builder · пише игратаagent actor · CLIфайловеФайлове на игратаartifacts/

    Builder записва входния файл, изходния код и ресурсите като артефакти.

  10. Builder · пише игратаagent actor · CLIзапис на изгражданетоtranscript.jsonl · append-onlysrc/transcript

    Събитието build и artifact.created се записват в стенограмата заедно с идентичността на артефакта.

  11. Изпълнение на ефекти · стартиране на участнициsrc/dispatcher/live.tsqa_checkQA на изпълнението · проверкиdispatcher/qa-runner.ts

    След събитие build reducer излъчва ефект qa_check, който носи идентичността на артефакта и изграждането и условията за приемане, а dispatcher го изпълнява.

  12. Файлове на игратаartifacts/какво се изпълняваQA на изпълнението · проверкиdispatcher/qa-runner.ts

    QA на изпълнението пуска реалния артефакт с проверки на кода и в браузъра. Времевият лимит по подразбиране от 120 секунди е стойност от конфигурацията.

  13. QA на изпълнението · проверкиdispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    При успех или неуспех резултатът се записва като системно събитие qa.result. Дори проверката да хвърли изключение, се записва резултат с неуспешните полета.

Граница на доверие при проверката

QA на изпълнението е доказателство от реалното пускане на артефакта; Verifier е модел, който преценява проектирани доказателства. Reducer съгласува двете, преди да избере следващия път.

  1. QA на изпълнението · проверкиdispatcher/qa-runner.tsqa.resulttranscript.jsonl · append-onlysrc/transcript

    При успех или неуспех резултатът се записва като системно събитие qa.result. Дори проверката да хвърли изключение, се записва резултат с неуспешните полета.

  2. transcript.jsonl · append-onlysrc/transcriptсамо доказателстваПроекция на входа за съдиятаsrc/dispatcher/live.ts

    Входът на Verifier се проектира от последните goal, spec, build, qa.result и artifact.created плюс избрани доказателства от проучването. Той стеснява контекста; не доказва изолация или липса на изтичане.

  3. Проекция на входа за съдиятаsrc/dispatcher/live.tsвход за съдиятаVerifier · вердикт на моделаVerifier actor

    Dispatcher изпълнява Verifier с проектирания вход.

  4. Verifier · вердикт на моделаVerifier actorjudge.scoretranscript.jsonl · append-onlysrc/transcript

    Вердиктът на Verifier се записва като събитие judge.score. Това е преценка на модел, а не факт за изпълнението.

  5. Състояние → следващи ефектиsrc/reducerоценка · доказателства от QAЗащита от заблуда · корекция на оценкатаsrc/validator

    При judge.score reducer го подава на проверката за защита от заблуда заедно с резултата от QA, доставчика на Builder и плана и доказателствата от проучването.

  6. Защита от заблуда · корекция на оценкатаsrc/validatorкоригиран вердиктМаршрутизиране по вердиктsrc/reducer

    PASS без успешно изпълнение става FAIL, а свързаната с изпълнението оценка се коригира по детерминистичния QA. Останалите правила са условни корекции, а не общо доказателство за правдивост.

  7. Маршрутизиране по вердиктsrc/reducerготовоГотово · PASS или причина за спиранеsession done

    PASS приключва сесията като done. Спиранията поради бюджет и circuit също приключват като done, но запазват причината за спиране, така че done не винаги е PASS.

Неуспех и човешко насочване

PARTIAL отива при човек, Critical за преработка на дизайна, Important или Minor за поправка, а спиранията поради бюджет или circuit оставят причина за спиране.

  1. Защита от заблуда · корекция на оценкатаsrc/validatorкоригиран вердиктМаршрутизиране по вердиктsrc/reducer

    PASS без успешно изпълнение става FAIL, а свързаната с изпълнението оценка се коригира по детерминистичния QA. Останалите правила са условни корекции, а не общо доказателство за правдивост.

  2. Маршрутизиране по вердиктsrc/reducerпроверка PARTIALИдея за игра · насочване

    PARTIAL чака проверка от човек.

  3. Маршрутизиране по вердиктsrc/reducerпреработка на дизайна · поправкаsrc/dispatcher/live.ts

    От FAIL и REJECT Critical се връща към Planner за преработка на дизайна, а Important или Minor към Builder като обратна връзка за поправка, всички изпълнявани като ефекти на dispatcher.

  4. Маршрутизиране по вердиктsrc/reducerготовоГотово · PASS или причина за спиранеsession done

    PASS приключва сесията като done. Спиранията поради бюджет и circuit също приключват като done, но запазват причината за спиране, така че done не винаги е PASS.

  5. Идея за игра · насочванеидея · насочванеЗапис на команди в inboxpackages/studio

    Идеята за игра в един ред и насочването на естествен език се въвеждат в Studio, който записва команди в inbox. Studio никога не редактира стенограмата директно.

Възпроизвеждане и наблюдение

Изграждането на състоянието наново от стенограмата не изпълнява ефекти, а Studio чете същия запис, за да го покаже.

  1. transcript.jsonl · append-onlysrc/transcriptнови събития · възпроизвежданеЦикъл на събитията · възпроизвеждане · tailsrc/loop/coordinator.ts

    Записвачът валидира схемата, задава ULID и време и добавя в края. При възпроизвеждане миналите събития само минават през reducer; ефектите им не се изпълняват отново.

  2. Цикъл на събитията · възпроизвеждане · tailsrc/loop/coordinator.tsредуциране поредСъстояние → следващи ефектиsrc/reducer

    Събитията в реално време се редуцират едно по едно от опашка, като се запазва редът на ефектите на всяко събитие; самото диспечиране върви асинхронно.

  3. transcript.jsonl · append-onlysrc/transcriptчетене · SSEПреглед на събития · артефактиpackages/studio

    Studio чете стенограмата и артефактите и показва напредъка, метриките и артефактите чрез SSE. Това не е телеметрия, изпращана към отдалечена услуга.

Всички връзки с еднаква дебелина. Изберете поток, за да се откроят само неговият път и номерираните стъпки.

  • Плътна · посока на входа, резултатите и записите
  • Прекъсната · изпълнение, преценка, заявка
  • Дълга пунктирна · наблюдение и отчитане, отделно от преценката
  • Дебела черна линия · избраният поток; числата показват реда
  • Кутия · граница на код или състояние, с името в заглавието
  • Вътрешен етикет · компонент на тази граница
  • Пунктирна кутия · извън тази граница
  • Оранжев контур · където решава модел
  • Цикъл на събитията · reducer · dispatcher
  • Записи · настройка · артефакти
  • Детерминистични проверки · корекция
  • Studio · участници

Начертано по пътищата в кода при публичния къмит f5e17c0. Участниците са роли по време на изпълнение, различни от агентите за програмиране, използвани за изграждането на това хранилище.

Източник на състоянието
Стенограмата е източникът на състоянието, а reducer е чиста функция. Само dispatcher изпълнява странични ефекти (стартиране на участници, QA, запис на файлове), затова възпроизвеждането изгражда състоянието наново без ефекти.
Какво обхваща възпроизвеждането
Възпроизвеждането дава същото състояние; то не прави детерминистични генерациите на LLM или поведението на браузъра и мрежата.
Какво обхваща вердиктът
QA на изпълнението проверява само конфигурираните проверки, а оценката на Verifier е един канал от доказателства. Нито едно от двете не измерва всяко поведение на играта, дали е забавна или удовлетвореността на потребителите.