Robust Task

Workflow для надёжного выполнения сложных многошаговых задач. Он сохраняет план и доказательства в workspace на диске для восстановления контекста, проверяет план и каждый шаг через независимого ревьювера-субагента и направляет неудачи через ограниченные циклы retry с эскалацией к пользователю. Используй для критичных задач, где важна надёжность.

Для простых задач рассмотри Quick Task.

mcp__moira__start({ workflowId: "moira/robust-task", parentExecutionId: "none" })

Flow проходит семь фаз: UNDERSTAND → DECOMPOSE → VALIDATE → APPROVE → EXECUTE → VERIFY → DELIVER.

flowchart LR
    A[Понимание] --> B[Декомпозиция]
    B --> C[Валидация плана]
    C -->|проблемы| C
    C -->|чисто| D[Согласование]
    D -->|пересмотр| B
    D -->|ок| E[Выполнение шага]
    E --> F[Gate-ревью]
    F -->|провал| E
    F -->|пройдено| G{Ещё шаги?}
    G -->|да| E
    G -->|нет| H[Проверка критериев]
    H --> I[Финальное ревью]
    I -->|пробелы| H
    I -->|ок| J[Результат]

Первый шаг проверяет, есть ли у агента доступ к файловой системе (инструменты Read/Write/Edit). Остальной flow подстраивается под ответ.

С доступом к файлам (предпочтительно) workflow создаёт workspace и работает с диска:

• Папка workspace: ./moira-ws/{task-name}-{YYYYMMDD}-{HHMM}/ (путь заканчивается слешем, хранится в workspace_path).
• План живёт в {{workspace_path}}plan.md (один нумерованный пункт на шаг).
• Требования фиксируются в {{workspace_path}}task-requirements.md; стандарты планирования — в {{workspace_path}}planning-standards.md; process ID — в {{workspace_path}}process-id.txt для восстановления после архивации сессии.
• Доказательства по шагам пишутся в {{workspace_path}}step-{{current_step}}/evidence.md.
• Агент передаёт пути, а не содержимое: декомпозиция возвращает total_steps и plan_saved_to_file — она НЕ возвращает массив плана обратно. Ревьюверы получают пути к файлам и читают артефакты напрямую.

Без доступа к файлам flow откатывается к состоянию в контексте: план живёт только в памяти workflow. Декомпозиция должна вернуть полный массив steps[] плюс current_step_action и current_step_expected_output для шага 1, а каждый complete-step возвращает action и expected output следующего шага.

Декомпозиция создаёт столько шагов, сколько задаче реально нужно — у маленьких задач их может быть несколько, у больших — много. План не раздувается и не обрезается под целевое число; решает реальный объём задачи.

Шаги декомпозиции и валидации применяют единый канон стандартов планирования:

Проверка никогда не полагается на суждение самого выполняющего агента. Запускаются два слоя независимого ревью плюс лёгкий self-проход перед финальным.

После выполнения каждого шага verify-step-execution делегирует gate-ревью независимому ревьюверу-субагенту (исполнитель не ревьюит свою работу). Ревьювер:

• Читает полный план и доказательство шага напрямую — без доверия к summary.
• Оценивает шаг на целостность плана: корректно ли он опирается на предыдущие шаги и готовит будущие, без дрейфа, регрессий и деградации качества?
• Проверяет, что доказательство полностью соответствует expected_output шага (частичное соответствие, отсутствие конкретного доказательства или пропущенные элементы — всё считается НЕ подтверждено).
• Возвращает step_verified (yes/no), issues_found и verification_details.

Вердикт ревьювера авторитетен. При no (с доступом к файлам) проблемы записываются в {{workspace_path}}step-{{current_step}}/verification-issues.md.

Когда все шаги завершены, проверка завершённости проходит в два прохода:

1. verify-criteria — лёгкий self-проход (pre-pass). Агент заново сверяет каждый success criterion с реальным артефактом (код, файлы, вывод команд, тесты), по одному критерию за раз, требуя конкретное доказательство на каждый. «Выглядит готовым» / «должно работать» / «описано как готовое» — это пробел, а не доказательство.
2. final-review — независимое финальное ревью. Ревьювер-субагент заново выводит покрытие success criteria из зафиксированных требований и реальных артефактов (не из заявлений исполнителя), по одной проверке на критерий, возвращая final_issues_count (0 = полностью покрыто) и плоский список пробелов.

Если финальное ревью находит пробелы, flow направляется в fix-gaps и перепроверяет.

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

Когда gate-ревью шага проваливается, цикл retry инкрементирует step_retry и повторяет с фидбеком ревьювера до max_retries. При исчерпании отправляется Telegram-уведомление, и пользователя просят выбрать:

На точке согласования present-plan ждёт явного yes/no от пользователя. Всё, кроме чистого «да» — включая «Да, но…» или «Хорошо, только измени…» — трактуется как plan_approved: no, и flow направляется через ветку revise-plan (не teleport). Агент записывает замечания в revision_feedback и не исправляет план сам; пересмотром управляет workflow.

Во время выполнения, если оставшийся план больше не соответствует уже построенному, агент использует переход teleport-replan. Он не начинает заново с шага 1:

1. Текущий шаг закрывается как есть — записывается честно, даже если частично.
2. Завершённые шаги (1..current) сохраняются нетронутыми.
3. Незавершённая часть текущего шага переносится вперёд в новый следующий шаг.
4. Переформируется или расширяется только хвост (шаги после текущего) под причину пересмотра.
5. Шаги пересчитываются, и total_steps обновляется.
6. Курсор продвигается, и пересмотренный план перепроверяется.

Счётчиком шагов владеет движок. Expression-ноды продвигают current_step (current_step = current_step + 1) и сбрасывают step_retry в 0; агент никогда не делает арифметику и не должен менять current_step сам. Условие check-all-steps-done сравнивает current_step с total_steps, чтобы решить, выполнять следующий шаг или переходить к проверке завершённости.

{
  "type": "expression",
  "id": "expr-inc-current-step",
  "expressions": [
    "current_step = current_step + 1",
    "step_retry = 0"
  ],
  "connections": { "default": "check-all-steps-done" }
}

Каждый шаг должен производить проверяемое доказательство, а не заявление «готово».

С доступом к файлам доказательство пишется в {{workspace_path}}step-{{current_step}}/evidence.md; ревьюверы читают его напрямую.

Flow отправляет Telegram-уведомление в трёх точках (и продолжается, даже если отправка не удалась):

• План готов — проверенный план готов к подтверждению пользователем.
• Эскалация — шаг провалился после max_retries, требуется решение.
• Завершение — задача выполнена, deliverable готов.

• Реализовать feature с тестами и проверкой
• Написать и опубликовать статью
• Провести исследование и подготовить отчёт
• Любая многошаговая задача с проверяемым выполнением и восстановлением после потери контекста

• Quick Task — Для простых задач
• Content Creation — Для создания текстового контента
• Verified Research — Для исследования с верифицированными источниками
• Обзор шаблонов — Все доступные шаблоны