Процессы команды и работа с агентами
У команды два связанных процесса: движение задач в трекере и движение изменений в Git. Работа с агентами описывает, как они выполняют эти процессы: откуда берут задачи, что делают сами и где требуется решение человека. Проектные команды сборки, тестирования, миграций и работы со средами остаются в литературе продукта.
Документы и границы
| Документ проекта | Основное содержание | Форма и пример |
|---|---|---|
| Процесс задач | Статусы и поля трекера, переходы, условия готовности и завершения, ответственность | task-workflow.md · Пример |
| Git-процесс | Ветки, MR, ревью, повторные проверки, интеграция и выпуск | git-workflow.md · Пример |
| Работа с агентами | Допуск через чат/трекер, полномочия, связь с запуском, точки HITL и продолжение | task-route.md · Пример |
У правила одно место: статусная модель не переписывает Git-регламент, маршрут агента ссылается на оба процесса. Мониторинг выбирает нужные переходы и подтверждения в своём плане; перечень событий сборщика не включается в документы команды.
Как подготовить
- Получить фактические настройки и правила трекера, Git и CI, приёмки и интеграции. Для временных систем описать их реальные правила и отличия от целевых.
- С командой заполнить процесс задач: основной путь, возвраты, роли, решения и условия завершения. Достаточно выбранного потока, не требуется описывать все процессы предприятия.
- Заполнить Git-процесс: база, рабочие ветки, MR, ревью, исправления и merge. Проверить независимый деплой ревизии задачи на подготовленную среду; при ограничениях адаптировать CI/CD по инфраструктурному гайду.
- Связать правила: какие условия Git разрешают переход задачи, как ветка/MR ссылаются на задачу. Условия приёмки и завершения не дублировать.
- По гайду работы с агентами определить выбранные способы запуска, права, адресатов, точки HITL и возвраты. Использовать существующие переходы и решения; не вводить статусы ради агента.
- Сохранить версии и подтверждения участников, подключить документы агенту через навыки/заметки. Проектные команды и практики — по форме онбординга.
- Проверить применение на PoC, сохранить результаты и устранить расхождения. При переходе к Пилоту актуализировать адресатов и полномочия, сохранив условия продуктовой приёмки.
Проверка процессов на PoC
Применение процесса задач и маршрута агента проверяется в FLOW-09 журнала PoC:
| Проверочный сценарий | Ожидаемое исполнение маршрута | Результат / доказательство | Проверивший и дата |
|---|---|---|---|
| Обычный путь до завершения | … | … | … |
| Вопрос → ожидание → ответ → возобновление | … | … | … |
| Замечание → исправление → повторная проверка | … | … | … |
| Нет ответа / повтор события / ошибка обновления статуса | … | … | … |
| Изменение объёма / передача человеку / отмена | … | … | … |
Проверить каждый выбранный способ запуска: сообщение чата и/или статус трекера, повторное поручение и повторную выборку без второго выполнения, отсутствие запуска при неготовой постановке. На PoC ИИ-инженер ведёт калибровочные задачи с командой; на Пилоте — участники продукта при инженерном сопровождении.
Применение Git-процесса проверяется в FLOW-10 того же журнала:
| Сценарий | Ожидаемый результат | Доказательство / проверивший / дата |
|---|---|---|
| Рабочая ветка от правильной базы, MR в нужную цель | … | … |
| Независимый деплой двух ревизий разных задач на разные среды | Ревизии и артефакты верны, задачи не смешиваются, соседняя среда не меняется | … |
| Смена задачи на среде при незавершённом старом pipeline | Устаревший запуск не может заменить новое развёртывание; если используются служебные ветки, их переназначение проверено | … |
| Маршрут ревью на PoC и заданный маршрут Пилота | … | … |
| Замечание → исправление → проверки → ответ → повторное ревью | … | … |
| Конфликт / смена базы / новое изменение после одобрения | … | … |
| Merge уполномоченным исполнителем, связь с задачей и версией | … | … |
Не возникшие естественно случаи проверяются как явно обозначенные пробные кейсы в разрешённом контексте. Техническая проверка и качество результата фиксируются отдельно. Детальные ограничения доработок и требования к вердиктам сохраняются в регламенте ревью.