Сначала правила — разделяем дизайн и сборку игры

Старый AI-пайплайн имел одного агента, делающего две работы одновременно: проектировал игру (правила, фазы, ресурсы, условия победы) и собирал GraphDoc JSON (ноды, ActionFlow, переходы, конфиги плагинов). Результат? Четырнадцать минут на генерацию простой карточной игры «Война». Двенадцать graph_updates. Пятнадцать раундов тул-коллов. Переполнение контекста. Пассивный пользователь, смотрящий на спиннер.

Диагноз был ясен: один агент решал две принципиально разные проблемы. Гейм-дизайн требует креативности, вкуса и человеческого суждения. Сборка графа требует знания DSL, ссылок на хэндлеры и структурной точности. Заталкивание обоих в одно контекстное окно означало, что ни одному не уделялось достаточно внимания.

ADR-014 разделил их на два контура:

Designer (Human-in-the-loop) — диалог между пользователем и AI-дизайнером. Дизайнер знает паттерны гейм-дизайна, но ничего не знает про DSL или JSON. Он производит Rules-Markdown: структурированный, человекочитаемый документ, описывающий фазы, ресурсы, действия и условия победы. Пользователь видит правила в RulesPane, правит через чат, итерирует за секунды.

Builder (Компилятор) — запускается, когда пользователь нажимает «Собрать игру». Builder знает DSL, хэндлеры и ActionFlow. Он не придумывает правила — он транслирует утверждённый Rules-Markdown в GraphDoc JSON. Три-пять graph_updates вместо двенадцати.

Rules-Markdown — третий DSL в системе (после текстовых правил и GraphDoc JSON). Он достаточно структурирован для машинной трансляции, но достаточно читаем для людей. Он живёт в GraphDoc.design.rulesMarkdown и становится единым источником правды для правил игры.

Эффект был драматичным. Итерация дизайна сократилась с 14 минут до 15-30 секунд на первый драфт. Пользователь — активный участник, а не пассивный зритель. И когда граф ломается, можно понять — правила были неправильные или компиляция сбилась — что было невозможно с монолитом.

Это была первая крупная декомпозиция AI-пайплайна. Но не последняя.