Очередь задач

Пока мы запускали задачи вручную, порядок был виден в командах: сначала дневник, затем отчёт. Когда задач станет больше, этот порядок придётся хранить явно. Иначе отчёт может стартовать до появления PainEntry, а два исполнителя одновременно изменят один файл.

Планировщик выбирает готовую задачу. Runner выполняет один запуск. Агент решает, как сделать порученное изменение в заданных границах. Эти обязанности полезно различать даже тогда, когда они реализованы в одном скрипте.

Разложите следующую функцию ALGI

Предположим, после локального отчёта нужен интерфейс его просмотра и отправка врачу. Ниже план возможного продолжения; интерфейс и отправка в стенде пока не реализованы.

Задача	Зависит от	Что нужно до старта
A. Согласовать состав отчёта	Решения владельца продукта.	Правила работы с заметками, псевдонимом и порядком записей.
B. Доработать расчёт отчёта	A.	Принятая спецификация и тестовые данные.
C. Сделать экран просмотра	A.	Согласованный формат ответа и состояния загрузки, пустого списка, ошибки.
D. Проверить экран с реальным расчётом	B и C.	Общая сборка и интеграционные проверки.
E. Подготовить отправку врачу	D и отдельного решения о передаче данных.	Получатель, подтверждение, права, обработка повторной отправки.

B и C можно выполнять параллельно после согласования интерфейса. D ждёт их объединённого результата. E может оставаться заблокированной даже при готовом коде: разрешение на передачу данных не следует из успешной сборки.

Что означает «готова к запуску»

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

В многопроцессном планировщике выбор задачи нужно совмещать с её захватом: два исполнителя не должны одновременно получить одну запись очереди. У выполнения должен быть владелец и срок действия захвата. Если исполнитель перестал отвечать, задача не возвращается в очередь вслепую: сначала проверяется, какие внешние действия он успел сделать.

Отдельные рабочие копии и объединение

Каждая параллельная задача получает свою ветку и рабочую копию, например Git worktree. Это защищает от одновременной записи в один файл, но не устраняет смысловые конфликты. Backend может изменить название поля, а интерфейс продолжит читать старое, хотя Git объединит изменения без конфликта строк.

Поэтому после объединения B и C нужен повтор проверок на общей версии. Запуск тестов каждой ветки по отдельности не заменяет этот шаг. Общую базу или тестовый внешний сервис также придётся разделить по задачам либо ограничить параллелизм.

Учебные v01-v03 не управляют очередью и захватом задач. Более того, ID журналов в них может совпасть у двух одинаковых задач, запущенных в одну секунду. До добавления параллелизма исправьте идентификацию запусков и определите, кому принадлежит каждая рабочая папка.

Где нужен фиксированный порядок

При исправлении бага заранее неизвестно, какие файлы агент прочитает и сколько проверок выполнит. Эту часть можно оставить поисковому циклу с ограничением времени и попыток.

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

Повторы здесь тоже различаются. Повторить unit-тест обычно допустимо. Повторить отправку после тайм-аута без проверки статуса может означать отправить письмо дважды. Нужны идентификатор операции и способ выяснить её результат.

Когда помогает второй агент

Параллельный исполнитель полезен, если может работать независимо: например, проверять интерфейс по согласованному API, пока первый меняет расчёт. Отдельный ревьюер полезен, если проверяет основания решения, запускает дополнительные тесты или использует другой набор примеров.

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

Для упражнения возьмите таблицу выше и запишите порядок выполнения после сбоя задачи C. Какие результаты можно сохранить, какие проверки придётся повторить и когда E станет доступна? Если ответы зависят от памяти автора, добавьте недостающие состояния в описание очереди.