brainstorm

name	brainstorm
description	Проведение brainstorm-сессии (мозгового штурма) с конструктивным конфликтом через orchestrate-команду: фасилитатор направляет обсуждение, участники отстаивают позиции, итог — протокол с решениями и планом действий

Brainstorm (мозговой штурм)

Сессия brainstorm с конструктивным конфликтом. Работает через dynamic-цепочку — фасилитатор направляет спор, участники защищают позиции, финал — протокол с решениями, ответственными и планом действий.

Когда использовать

• Нужно принять архитектурное или продуктовое решение с несколькими альтернативами
• Есть спорный вопрос, где важно услышать разные точки зрения
• Требуется протокол обсуждения с конкретными решениями и планом действий
• Планирование эпика или релиза, где нужны аргументы «за» и «против»

Как использовать

Шаг 1: Формулировка темы

Сформулируй тему brainstorm — один-два предложения, описывающие проблему или вопрос для обсуждения.

Требования к теме:

• Конкретная, а не абстрактная (плохо: «архитектура», хорошо: «какие модули выделить из AgentRunner»)
• Содержит контекст, чтобы участники могли сразу включиться
• Формулируется на языке, понятном всем участникам

Шаг 2: Выбор участников

Пререквизит: цепочка brainstorm должна быть определена в config/chains.yaml.

Подбери участников вручную — не полагайся только на дефолты из config/chains.yaml. Цель: собрать как можно больше разных точек зрения на проблему.

Как выбирать:

1. Прочитай description каждой роли в docs/agents/roles/team/ — пойми, какую экспертизу и стиль мышления она несёт.
2. Выбери 3–6 ролей с разными направлениями: архитектура, разработка, аналитика, тестирование, документация. Чем разнообразнее — тем продуктивнее конфликт.
3. Старайся включить хотя бы одну роль с противоположным взглядом на проблему (например, стратег + скептик).

Принцип: не существует «правильного» набора участников. Главное — разные точки зрения и готовность спорить.

Переопределение участников — через --participants при запуске (Шаг 3).

Шаг 3: Запуск brainstorm

    php vendor/bin/task-orchestrator agent:orchestrate "<тема>" --chain=brainstorm [опции]

⚠️ Опция --chain=brainstorm обязательна: по умолчанию команда запускает цепочку implement, а не brainstorm.

Опции:

Опция	Сокращение	Описание	Значения	По умолчанию
--chain	-c	Имя цепочки	имя цепочки	implement ⚠️ укажите brainstorm
--facilitator		Роль фасилитатора (dynamic)	имя роли	team_lead_alex ¹
--participants		Участники через запятую (dynamic)	имена ролей	system_architect_gandalf,... ¹
--max-rounds		Макс. раундов обсуждения (dynamic)	число	20 ¹
--timeout	-t	Таймаут на шаг, секунды	число	600 ¹
--max-time		Макс. время сессии, секунды (dynamic)	число	3600 ¹
--topic		Тема (если отличается от аргумента task)	текст	= task
--dry-run		Показать план без запуска	—	выкл
--report-format		Формат отчёта	text, json, none	text
--report-file		Путь к файлу отчёта	путь, например var/sessions/brainstorm/<name>-%Y-%m-%d_%H-%M-%S.md	stdout
--no-audit-log		Отключить audit-логирование	—	выкл
--no-context-files		Отключить загрузку AGENTS.md/CLAUDE.md	—	выкл
--resume		Путь к директории сессии для resume	путь	—
--working-dir	-d	Рабочая директория	путь	корень проекта

¹ Значение по умолчанию берётся из config/chains.yaml, если опция не передана.

Приоритет опций: CLI-аргумент > значение из config/chains.yaml > CLI-дефолт. Если опция передана явно — она всегда побеждает.

Примеры:

    # Стандартный brainstorm
    php vendor/bin/task-orchestrator agent:orchestrate "Какие модули выделить из AgentRunner" --chain=brainstorm

    # Переопределение участников и лимита раундов
    php vendor/bin/task-orchestrator agent:orchestrate "Стратегия тестирования" \
        --chain=brainstorm \
        --participants=system_analyst_sherlock,system_architect_gandalf,system_architect_loki \
        --max-rounds=15

    # Другой фасилитатор + отчёт в файл
    php vendor/bin/task-orchestrator agent:orchestrate "Кэширование в оркестраторе" \
        --chain=brainstorm \
        --facilitator=team_lead_alex \
        --participants=backend_developer_levsha,system_architect_gandalf \
        --report-format=text \
        --report-file=var/sessions/brainstorm/cache-strategy-$(date +%Y-%m-%d_%H-%M-%S).md

    # Dry run — посмотреть план без запуска
    php vendor/bin/task-orchestrator agent:orchestrate "Паттерн retry" --chain=brainstorm --dry-run

    # Resume прерванной сессии
    php vendor/bin/task-orchestrator agent:orchestrate "Продолжение brainstorm" \
        --chain=brainstorm \
        --resume=var/sessions/brainstorm/2026-04-23_03-02-36

Resume прерванной сессии

Brainstorm может быть прерван по таймауту шага, исчерпанию бюджета, ошибке агента или вручную (Ctrl+C). В таком случае сессия сохраняется в состоянии interrupted и её можно продолжить.

Зачем: brainstorm — долгий процесс (до 20 раундов). Потеря прогресса из-за сбоя на 15-м раунде — критична. Resume позволяет продолжить с того места, где остановились, не повторяя уже завершённые раунды.

Что сохраняется:

• topic, facilitator, participants, max_rounds — исходные параметры сессии
• completed_rounds — количество завершённых раундов
• discussion_history — вся история обсуждения
• facilitator_journal — журнал фасилитатора (оценки, решения по routing)
• audit.jsonl — полный аудит вызовов агентов

Как запустить resume:

1. Найди директорию прерванной сессии: var/sessions/brainstorm/<timestamp>/
2. Запусти команду с --resume:

    php vendor/bin/task-orchestrator agent:orchestrate "<тема>" --chain=brainstorm \
        --resume=var/sessions/brainstorm/<timestamp>

Тонкости:

• Опции --facilitator, --participants, --max-rounds, --topic игнорируются — используются значения из прерванной сессии, сменить состав участников нельзя.
• --timeout действует — можно увеличить таймаут, если сессия прервалась по лимиту на шаг.
• --max-time действует — можно увеличить общее время сессии, если она прервалась по max_time_exceeded.
• --chain должен совпадать с исходной цепочкой (обычно brainstorm).
• Аргумент task обязательный, но при resume используется только как контекст для фасилитатора — фактическая тема берётся из сессии.
• Resume можно вызывать несколько раз: если после resume сессия снова прервалась — можно сделать resume повторно.

Шаг 4: Анализ результата

После завершения brainstorm:

1. Проверь код возврата: 0 — сессия завершена с синтезом (протоколом), 1 — прервана (таймаут, бюджет, ошибка).
2. Прочитай протокол — result.md в каталоге сессии.
3. Если нужно глубже разобраться — изучи файлы сессии (см. ниже).

Каталог сессии: var/sessions/<chain>/<timestamp>/

Файл	Содержание
topic.md	Тема brainstorm
session.json	Метаданные: статус, раунды, участники, фасилитатор
discussion_history.md	Полная история обсуждения — все реплики участников
facilitator_journal.md	Журнал фасилитатора: оценки, решения по routing, итоги
result.md	Финальный протокол: synthesis + метрики
step_XXX_round_YYY_<role>_1_system.md	Системный промпт для роли на данном шаге/раунде
step_XXX_round_YYY_<role>_2_user.md	Пользовательский промпт (контекст для роли)
step_XXX_round_YYY_<role>_3_response.md	Ответ роли — позиция, аргументы, контраргументы
audit.jsonl	Технический аудит: токены, стоимость, latency

Для анализа в первую очередь читай result.md (принятые решения, action items, метрики). Если нужен контекст — discussion_history.md (кто что говорил, какие аргументы убедили). Для понимания решений фасилитатора — facilitator_journal.md. Для нюансов позиции конкретной роли — step_XXX_round_YYY_<role>_3_response.md. audit.jsonl — для отладки.

Структура протокола (result.md):

• Участники и повестка
• Ключевые разногласия и разрешённые конфликты
• Принятые решения с обоснованием
• План действий (Action Items) с ответственными

Шаг 5: Работа с результатом

На основе протокола brainstorm:

1. Зафиксируй принятые решения в соответствующих документах (архитектура, задачи, epic).
2. Создай задачи на Action Items из плана действий — каждую с ответственным и критерием готовности.
3. Если brainstorm проводился в рамках эпика — обнови план эпика с учётом решений.

Результат

Основной: Протокол собрания (stdout или файл из --report-file).

Поля протокола:

Поле	Описание
Участники	Кто участвовал и в какой роли
Повестка	Формулировка темы обсуждения
Ключевые разногласия	Где участники не пришли к согласию
Разрешённые конфликты	Где спор привёл к новому пониманию
Открытые вопросы	Неразрешённые разногласия
Принятые решения	Решение + обоснование + альтернатива
План действий	Задача + ответственный + приоритет + критерий готовности

Побочные: Каталог сессии var/sessions/<chain>/<timestamp>/ со всеми артефактами (см. Шаг 4).

Чеклист самопроверки:

• Тема конкретная и содержит контекст
• Участники подобраны под цель brainstorm
• Протокол содержит все обязательные поля (повестка, решения, план действий)
• Action Items имеют ответственных и критерии готовности
• Принятые решения зафиксированы в задачах или документах

Связанные скиллы

Скилл	Когда использовать
retrospective	После реализации решений из brainstorm — подвести итоги
run-subagent	Если brainstorm проводится через сабагента
epic-via-subagents	Если brainstorm — часть эпика