Todo List

Todo List превращает одну цель в упорядоченный checklist и выдаёт по одной задаче. Это намеренно не журнал результатов: workflow не классифицирует исходы задач, не агрегирует evidence и не строит итоговый отчёт.

Запуск workflow

mcp__moira__start({ action: "prepare", workflowId: "moira/todo-list", parentExecutionId: "none" })
mcp__moira__start({ action: "execute", startAttemptId: "<ID попытки запуска из prepare>" })

Первый шаг получает от 1 до 100 задач. Если в текущем контексте пользователя или вызывающей стороны уже есть корректный по схеме готовый список, его содержание остаётся за автором: каждый пункт передаётся с неизменной формулировкой и объёмом, ничего не выбрасывается и не дописывается незаказанная работа. Очередь принадлежит исполнителю: пункты ставятся туда, где их предпосылки уже выполнены, замечание, управляющее всей работой, привязывается к пунктам, которые оно ограничивает, а не исполняется отдельной задачей, и если получившийся порядок расходится с написанным, расхождение и вызвавшая его зависимость видны автору до начала работы. Иначе тот же шаг один раз составляет список из текущей цели. Каждая задача содержит только:

• action: самодостаточную работу, которую нужно выполнить;
• expected_result: наблюдаемое условие завершения.

Обе строки непустые и ограничены 1 000 символами. Позиция в массиве служит идентификатором задачи; агент не передаёт ID, курсор, общее число, статусы или коды результата.

Выполнение

Todo List владеет курсором с единицы. Он проецирует текущую задачу, сообщает агенту действие и ожидаемый результат и ждёт. Агент выполняет реальную работу и проверяет результат до вызова step() с локальным evidence и ограниченным результатом для отображения:

{
  "evidence": "Целевая команда тестов прошла.",
  "progress_execution_outcome": "Затронутый набор тестов прошёл"
}

Обе строки непустые и имеют длину не больше 500 символов. evidence — конкретное подтверждение текущего шага; оно остаётся локальным для ноды и не копируется в глобальный массив или терминальный отчёт. progress_execution_outcome заменяет последнюю подтверждённую сводку Work только для отображения; это не evidence, и само по себе значение не продвигает курсор.

Если задача не завершена или заблокирована, агент не вызывает step(). Он сообщает пользователю проверенную причину, поэтому курсор остаётся на текущей задаче. Корректное по JSON Schema подтверждение продвигает курсор ровно один раз. Исчерпание упорядоченного массива завершает workflow.

Прогресс выполнения

Карточка запуска и экспортируемое изображение используют три блока: Checklist → Prepare → Work. Checklist показывает последнюю подтверждённую сводку авторитетного упорядоченного списка. Prepare отражает уже существующее вычисление длины, курсора, действия и ожидаемого результата движком. Work включает как обычное выполнение задачи, так и исправление checklist, который перестал описывать оставшуюся работу.

Текущая роль всегда названа явно. Обычная работа имеет подпись Task N/M и показывает полное текущее действие; полный ожидаемый результат остаётся в директиве агента, поскольку может быть длиннее ограниченного поля прогресса. Переход к исправлению списка имеет подпись Revise checklist и не использует проекцию задачи, которая на таком маршруте может отсутствовать. Обе роли принадлежат последнему блоку Work, поэтому и обычное завершение, и пересмотр с удалением всего оставшегося хвоста завершают прогресс без искусственного итогового шага.

Результаты Checklist и Work — ограниченные значения только для отображения. Пересмотр заменяет сводку checklist и атомарно сохраняет только всё ещё истинный результат задачи из неизменённого завершённого префикса либо Pending. Прогресс не участвует в условиях, арифметике курсора, данных задач, evidence завершения, терминальном результате или полномочиях.

Пересмотр checklist во время выполнения

Когда неверным оказывается сам checklist — оставшиеся задачи устарели, чего-то не хватает или порядок неправильный, — агент переходит к ноде пересмотра, вместо того чтобы доводить до конца список, о неверности которого уже знает:

mcp__moira__step({ processId, attemptId, teleportTo: "teleport-revise-tasks" })

Это цель перехода (teleport): в неё не ведёт ни один шаг, поэтому пересмотр всегда осознанное решение. Это не способ уйти от задачи, которая просто сложна, заблокирована или падает, — для такого случая действует правило выше.

Шаг пересмотра запрашивает полный исправленный checklist и позицию, с которой продолжать:

{
  "tasks": [
    { "action": "…уже выполненная задача, без изменений…", "expected_result": "…" },
    { "action": "Исправить конфигурацию, ошибку в которой выявила первая задача", "expected_result": "Сервис запускается с исправленной конфигурацией" }
  ],
  "resume_from_task": 2,
  "progress_checklist_outcome": "Исправленный список сохраняет завершённый префикс и две оставшиеся задачи",
  "progress_execution_outcome": "Первая задача остаётся проверенной"
}

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

Передача готового checklist

Вызывающая сторона запускает Todo как дочерний workflow и включает готовый корректный по схеме массив задач в контекст дочерней задачи. Первый шаг Todo передаёт этот массив обычным ответом step():

{
  "tasks": [
    {
      "action": "Проверить реализованное требование",
      "expected_result": "Предметный отчёт вызывающей стороны содержит проверенный результат"
    }
  ],
  "progress_checklist_outcome": "Одна упорядоченная задача готова"
}

Отдельной ветки supplied tasks и pre-start input mapping нет. Intake-шаг сохраняет содержание готового массива, а не перепланирует его, упорядочивает его по зависимостям и начинает с первого пункта. Если два присланных пункта нуждаются в результате друг друга, ни один порядок не удовлетворяет обоим, и такая пара называется автору, а не выбирается молча. Предметные результаты остаются у вызывающей стороны. Например, workflow проверки требований должен сам записывать отчёт и владеть классификациями COVERED/GAP, а не использовать Todo List для их передачи.

Контракт завершения

Todo List завершается с пустым терминальным результатом: {}. Завершение означает, что каждый пункт checklist получил корректное по схеме подтверждение после выполнения и проверки агентом. Evidence отдельных пунктов остаётся в истории взаимодействия исполнения; накопленный output API для него не обещается.

Если вызывающему subgraph нужны предметные данные, он должен сформировать и сохранить их сам. Ветка Todo success означает только достижение End-ноды checklist.