Один промпт превращается в проверенное, протестированное, документированное и влитое изменение — пока пользователь занят другим делом. Pipeline состоит из 12 шагов и берёт на себя все они.

Pipeline

Что получает пользователь

  • Каждый Task работает в собственной изолированной ветке, поэтому параллельные Task не конфликтуют, а основной код остаётся в безопасности.
  • AI-ревью и автоматические исправления выполняются до того, как пользователь увидит результат.
  • Модульные и сквозные (end-to-end) тесты запускаются автоматически.
  • Результат проверяется на соответствие заданным критериям приёмки.
  • Документация и Behavioral Contracts обновляются автоматически.
  • Слияния ставятся в очередь, а сборка должна пройти успешно, прежде чем изменение будет принято.
  • При сбое AITM восстанавливается самостоятельно, а продолжить можно с любого шага.
  • Каждый Task оставляет читаемую сводку результата и историю.

12 шагов

  1. Branch — Task получает собственное безопасное рабочее пространство, которое не может конфликтовать с другими Task. Результат: основной код остаётся нетронутым, пока работа не будет готова.
  2. Architect — AI читает промпт и соответствующий код и планирует решение. Результат: продуманный план, какие части проекта изменятся.
  3. Code — план превращается в реальные изменения файлов. Результат: готовая реализация.
  4. Compliance-check — независимо сопоставляет diff с требованиями для сложных Task. Более простые Task пропускает, а любые замечания передаёт в Review. Результат: раннее уведомление о пропущенных требованиях.
  5. Review — AI проверяет работу как коллега и выносит вердикт. Результат: второй взгляд без ожидания человека.
  6. Fix — устраняет всё, что отметил Review; может несколько раз повторяться в цикле с Review. Результат: очищенный результат.
  7. Test — запускает автоматические модульные тесты проекта. Результат: уверенность, что изменение не нарушило существующее поведение.
  8. E2E — запускает тесты, управляющие приложением как реальный пользователь. Выполняется только если в проекте есть сквозные тесты, параллельно с Test. Результат: проверенный сценарий пользователя целиком.
  9. Verify — сравнивает результат с критериями приёмки Task; каждый из них получает итог passed, failed или unverifiable. Результат: чёткий ответ, делает ли Task то, что было запрошено.
  10. Snapshot — необязательный шаг, который делает снимки экрана UI. Результат: визуальная запись изменения.
  11. Docs — обновляет документацию и Behavioral Contracts в соответствии с изменениями. Выполняется всегда. Результат: документация, которая не устаревает.
  12. Chain-audit — работает только на последнем Task цепочки зависимых Task, повторно проверяя критерии каждого предыдущего Task. Результат: уверенность, что вся цепочка согласована.

Слияние не является шагом Pipeline — после последнего шага Task попадает в Merge queue, которая вливает его в ветку dev. До этого момента завершённый Task отображается с маркером Finalizing…. Подробности см. в Merging, Post-Merge Fixes & Scope Gate.

Консоль Pipeline
Представление Develop с двумя Task, выполняющимися параллельно — на каждой карточке своя консоль Pipeline с живым выводом.
Завершённый Task на этапе финализации и слияния
Завершённый Task, который финализируется и вливается в dev.

Где требуется участие человека

  • Просмотр результата Task — см. Чтение результатов и архив.
  • Редактирование промпта, если результат не соответствует замыслу.
  • Возобновление с определённого шага или повторная постановка Task в очередь, когда Pipeline остановился.

Если шаг завершился сбоем

Зависший шаг перезапускается автоматически; число повторов задаётся в Settings → Pipeline. Если после синхронизации с dev сборка красная, предпринимается попытка исправления, а конфликты слияния сначала пытаются разрешить с помощью AI. Если этого недостаточно, Task остаётся помеченным, и отображается причина. На карточке Task со сбоем или конфликтом при этом есть кнопка с предложением по восстановлению.

Полезно знать

  • Если нужно повторить только один из последних шагов, лучше возобновить с него, чем запускать весь Pipeline заново.
  • Результаты каждого Task можно прочитать в разделе Чтение результатов и архив.
  • Независимые Task выполняются параллельно, а зависимые Task можно объединять в цепочки.
  • Исправления ошибок должны быть подтверждены на реальном симптоме, а изменения за пределами заявленного Scope Task помечаются.
  • Сборка должна пройти до слияния, чтобы сломанный код не попал в dev.