BMAD + Beads + Gas Town: Как собрать «Святую Троицу» AI-разработки и перестать кодить вручную (но это не точно)
Вы уже видели скриншоты: десятки терминалов, работающих параллельно, агенты, которые сами пишут код, тестируют и мерджат. Это не магия, это оркестровка.

Многие пытались повторить это, подключая агентов к Jira или Trello, но спотыкались о главную проблему: контекст. Агенты «забывают», что делали час назад, а статические задачи в таск-трекере не отражают сложную логику зависимостей.

Сегодня разберем, как объединить три мощнейших инструмента в одну систему, которая работает как часы.
🏗 BMAD (Архитектор)
📿 Beads (Память)
🏙 Gas Town (Фабрика)

Зачем нам три инструмента?
Представьте, что вы строите дом.

BMAD - это архитектор и прораб, которые решают «Что строить и почему?». Они создают чертежи (PRD), планируют этапы и следят за стандартами.
Beads - это строительный журнал и склад в одном. Здесь хранятся все записи: «Что уже сделано? Что заблокировано? Где лежат кирпичи?». Это память, которая не исчезает после перезагрузки агента.
Gas Town - это бригада рабочих и мастерская. Это станки, которые «делают работу». Они берут чертежи, смотрят в журнал и строят стены параллельно, не мешая друг другу.
По отдельности они хороши, но вместе - это AI-фабрика.

Flow рабочего процесса

Шаг 1: Планирование (BMAD)
Вы начинаете как обычно.

Запускаете BMAD.
Агенты (Аналитик, PM, Архитектор) генерируют документацию: PRD, архитектуру, списки эпиков.
Ключевой момент: BMAD не просто создает markdown-файлы. Теперь эти артефакты становятся сырьем для Beads.

Шаг 2: Кристаллизация задач (Beads)
Это мостик между планом и исполнением.
Вам (или специальному агенту-секретарю) нужно конвертировать планы BMAD в задачи Beads.

Пример сценария:

BMAD-агент создал эпик «Система авторизации».
Вы преобразуете его в Beads:
bd create "Auth System" --type epic -p 0
BMAD-агент разбил эпик на истории? Переносим их:
bd create "Login Page" --type story --parent <epic-id>
bd create "Password Reset" --type story --parent <epic-id>
Зачем это нужно?
Потому что Gas Town не понимает markdown-планы. Он понимает граф задач с зависимостями. Beads превращает ваши красивые документы в машинно-читаемую структуру.

Шаг 3: Запуск производства (Gas Town)
Теперь в дело вступает оркестратор.

Mayor (Мэр) - главный агент Gas Town - опрашивает Beads:
bd ready --json
Он получает список задач, которые не заблокированы и готовы к работе.
Convoy (Конвой) - Мэр объединяет задачи в пачку (конвой) для параллельной обработки:
gt convoy create "Sprint 1" bd-abc12 bd-def34
Polecats (Рабочие) - создаются изолированные среды (worktrees) для каждой задачи:
gt sling bd-abc12 my-project
Агент начинает писать код в своей ветке, имея доступ к контексту задачи из Beads.

Шаг 4: Слияние и контроль (Refinery & Witness)
Пока Polecats пишут код, другие агенты следят за процессом:

Refinery решает конфликты слияния, аккуратно внося изменения в main.
Witness следит за «зависшими» задачами и помогает агентам, если они застряли.
После успешного слияния статус задачи в Beads меняется на Closed, и BMAD-документация может быть автоматически обновлена.

🧠 В чем фишка такой связки?
1. Решение проблемы «Контекстного окна»
Обычно агент «забывает» задачу, как только закрывает терминал. С Beads состояние хранится в git-backed базе данных. Gas Town перезагружает агентов, но они «помнят», на чем остановились, потому что читают состояние из Beads.

2. Разделение труда
BMAD фокусируется на спецификациях (SDD - Spec Driven Development). Gas Town фокусируется на операционной деятельности.
Это две разные парадигмы:

BMAD имитирует человеческую иерархию (Аналитик → PM → Дев).
Gas Town имитирует заводской конвейер (Мэр → Рабочий → Контролер).
Вместе они закрывают весь цикл: от идеи до готового кода.

3. Масштабирование
Один агент - это медленно. Gas Town позволяет запускать 20-30 агентов параллельно. Beads гарантирует, что они не наступят друг другу на пятки, правильно распределив зависимости.

👇