Как задача превращается в pull request

Это страница, на которую ссылается вся остальная документация. На ней указаны все этапы выполнения, чтобы в других статьях можно было точно определить место происхождения того или иного процесса.

Путь#

your description
   │
   ▼
   specification   what will be built, and how you will know it worked
   │
   ▼
   plan            the ordered steps, reviewed before any code is written
   │
   ▼
   build           code and tests written in an isolated workspace
   │
   ▼
   verify          your test suite, plus checks and quality gates
   │
   ▼
   review          an automated review pass over the diff
   │
   ▼
   pull request    on a branch, in your repository, waiting for you

Спецификация#

Coroid начинается не с вашего текста. Сначала ваше описание преобразуется в спецификацию: что именно будет создано, что явно не входит в область задачи и критерии приемки, по которым определяется успешность выполнения работы.

Это важно, потому что критерии приемки служат основой для проверки на следующем этапе. Нечеткая спецификация приводит к результатам, которые трудно оценить.

Вы можете просматривать и редактировать спецификацию на вкладке Спецификация перед началом выполнения задачи.

Руководство по разработке на основе спецификации объясняет, как формулировать критерии, поддающиеся проверке, устанавливать границы области задачи и сохранять единое понимание успеха на этапах планирования, реализации и рецензирования.

План#

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

Отклонение плана обходится дешево и является правильным решением, если подход ошибочен. Отклонение после написания кода — более затратный вариант. Именно на этом этапе ваше суждение имеет наибольший вес.

Разработка#

Агент клонирует репозиторий в изолированную рабочую область и работает там. Он читает код, вносит изменения и создает или обновляет тесты.

Рабочая область является временной и привязана к конкретной задаче. Ничто, что делает агент, не затрагивает вашу стандартную ветку, а две задачи, выполняющиеся одновременно, не могут видеть работу друг друга.

Проверка#

Сначала запускается ваш собственный набор тестов — это самый достоверный сигнал, поскольку он отражает то, что уже определено в команде как важное.

Помимо этого, ограничения качества применяют настройки вашей организации: пороги покрытия кода тестами, проверки стиля, сканирование на предмет уязвимостей, браузерные тесты на предварительном деплое. Блокирующее ограничение останавливает задачу; рекомендательное ограничение фиксирует результат в виде Результатов и позволяет продолжить работу.

Рецензирование#

Агент-рецензент анализирует различия в коде так же, как это сделал бы коллега, и формирует Результаты. Те из них, что требуют исправления, отправляются на доработку; остальные прикрепляются к pull request, чтобы вы их видели.

Именно поэтому Coroid pull request уже прошел рецензирование — не чтобы заменить вашу проверку, а чтобы ваша оценка не стала первой.

Запрос на объединение#

Ветка загружается в систему, и открывается pull request для вашей базовой ветки, содержащий изменения, тесты, результаты проверки и Результаты рецензирования.

Coroid завершает свою работу здесь. Объединение кода — ваша задача.

Статусы задач#

Статус задачи показывает, на каком этапе она находится в рамках описанного выше пути:

Что влияет на производительность#

Один слот агента обрабатывает одну задачу за раз. Слоты определяют, сколько задач выполняется параллельно; они не ускоряют выполнение отдельной задачи. Длительность задачи зависит от объема изменений и времени, необходимого для запуска ваших тестов.

Далее#

Роли агентов — какой агент отвечает за какой этап и что ему разрешено делать.