Перейти к содержанию

Доказательный процесс выполнения задач агентами

Статус: ДЕЙСТВУЕТ ТОЛЬКО В ОТДЕЛЬНОМ VERIFICATION/PROD-КОНТУРЕ.

Обновлено: 2026-08-26.

Цель

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

Этот процесс не запускается автоматически в обычной live STAGE-разработке. По решению 0032 он включается командой ПРОВЕРИТЬ, командой ПОДГОТОВИТЬ К ПРОДАКШНУ или отдельным прямым назначением verifier. Обычная итерация выполняется основным агентом напрямую: реализация → минимальная сборка/запуск → STAGE → ручная проверка владельцем → исправление.

Команда ПОДГОТОВИТЬ К ПРОДАКШНУ использует этот evidence process внутри более широкого gate из docs/PRODUCTION_READINESS.md: сначала audit и repair loop, затем независимые tester/reviewer и итог GO, NO-GO или BLOCKED. Этот итог не разрешает фактический PROD deploy.

Роли процесса

Фактические project-scoped профили и их routing boundaries определены в docs/AGENT_ROLES.md.

Роль Ответственность
orchestrator формирует контракт, назначает исполнителя и проверяющего, принимает или отклоняет handoff
executor выполняет задачу и собирает пакет доказательств
tester независимо проверяет поведение и edge cases
reviewer проверяет diff, безопасность, архитектуру и соответствие объёму
следующий агент принимает только статус ACCEPTED_FOR_HANDOFF и проверяемые входные артефакты

Один агент может выполнять несколько ролей только для низкорисковой задачи с детерминированными проверками. Для критической задачи автор изменения не является единственным проверяющим.

Карточка задачи

До начала работы координатор фиксирует:

task_id: stable-id
goal: проверяемый результат
scope:
  included: []
  excluded: []
acceptance_criteria: []
expected_artifacts: []
required_checks: []
permissions: []
dependencies: []
blocked_when: []
executor: role-or-agent
verifier: role-agent-or-ci

Не нужно создавать отдельный файл для каждой маленькой задачи: карточка может находиться в плане или задании агента. Для сложной, многоэтапной или межагентной работы она сохраняется в проектном task log.

Внешний UI/UX-reference

Внешний UI/UX-агент не является Product-code executor. Владелец или внутренний координатор заполняет единственную текущую задачу docs/ui-agent/TASK.md. До публикации developer-сайта агент изучает явно перечисленный в задаче снимок product-репозитория, после публикации — полный developer-сайт; в обоих случаях он учитывает docs/ui-agent/memory/ и затем сохраняет reference package в docs/ui-agent/results/<task-id>/revision-<task-revision>/.

Task state изменяет только владелец или координатор. После получения EXTERNAL_RESULT_READY координатор ставит AWAITING_OWNER_REVIEW; та же ревизия повторно не запускается. После сообщения владельца о завершении внутренняя команда читает result folder, автоматически принимает его полным точным визуальным reference, фиксирует перенос в отдельной Product implementation task, переносит предложенные visual memory items в memory/ACCEPTED.md и возвращает TASK.md к EMPTY. Отдельные UI-аудит, tester/reviewer gate и повторная приёмка цветов, размеров, компоновки, таблиц, UI-ассетов, логотипов, иконок и UI-скриптов не выполняются. Запрошенная владельцем доработка увеличивает task_revision, получает новый revision-specific result_path и возвращает READY, не перезаписывая прошлый result.

Сам reference package, UI-kit board или standalone prototype автоматически принят как visual source of truth, но не является Product runtime artifact и сам по себе не разрешает Git, test-server deploy или production.

Внутренняя implementation task без переоценки дизайна переносит reference как есть. Обычная техническая проверка применяется только к сохранению Product routes, data, permissions, Auth/API contracts, собираемости и runtime; она не может отклонить или изменить принятый visual reference. Полный внешний contract определён в prompts/08-external-ui-ux-agent.md, рабочая область — в docs/ui-agent/, а причины решения — в ADR 0027, 0028 и 0031.

Пакет доказательств исполнителя

После выполнения исполнитель присваивает только READY_FOR_VERIFICATION и передаёт:

## Заявленный результат

## Артефакты и diff

## Матрица приёмки
| Критерий | Доказательство | Результат |

## Выполненные проверки

## Пропущенные проверки и влияние

## Ограничения и остаточный риск

## Как воспроизвести

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

Проверка

Проверяющий:

  1. Читает исходный контракт задачи, а не только отчёт исполнителя.
  2. Проверяет существование и состав артефактов.
  3. Сопоставляет каждый критерий приёмки с доказательством.
  4. Самостоятельно просматривает diff и повторяет проверки пропорционально риску.
  5. Проверяет негативные сценарии, permissions и границы, если они применимы.
  6. Убеждается, что пропущенная проверка не скрыта и не блокирует критерий.
  7. Выдаёт один результат: VERIFIED, REJECTED или BLOCKED.

В многоэтапном процессе verifier проверяет только назначенный ему текущий gate и входы для следующего этапа. Он не отклоняет текущий gate только потому, что запланированные последующие reviewer/orchestrator stages ещё не выполнены. Общая задача остаётся незавершённой до последнего gate, а каждый промежуточный handoff получает собственное проверяемое решение.

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

Решение координатора

Координатор проверяет, что:

  • verifier независим в требуемой степени;
  • все обязательные критерии имеют доказательства;
  • нет скрытых FAIL, BLOCKED или существенных пропусков;
  • итог не основан только на рассказе агента;
  • дальнейшее действие не требует нового разрешения владельца.

Только после этого присваивается ACCEPTED_FOR_HANDOFF и формируется задание следующему агенту с точными входными артефактами.

Для последовательности executor → tester → reviewer → orchestrator фиксируются отдельные переходы:

  • executor package принят tester или возвращён executor;
  • tester evidence принят reviewer или возвращён tester/executor;
  • reviewer conclusion принят orchestrator или возвращён на нужный этап;
  • orchestrator присваивает общий ACCEPTED_FOR_HANDOFF только после завершения обязательной цепочки.

Повторное использование проверок

Проверка из прошлой задачи может быть использована как вспомогательное свидетельство, но не заменяет текущую, если изменение могло повлиять на результат. Допустимость повторного использования подтверждается scope/diff-анализом.

Если тест технически нельзя выполнить, фиксируются причина и влияние. Критерий остаётся BLOCKED; формулировка «должно работать» не заменяет результат.

Связь с памятью и Skills

  • Доказанный повторяемый результат может быть сохранён в docs/agent-memory/.
  • Только проверенная процедура может получить статус VALIDATED, SKILL_CANDIDATE или ACTIVE.
  • Созданный или изменённый Skill сам проходит этот evidence gate.
  • Правила памяти и promotion описаны в docs/AGENT_MEMORY_AND_SKILLS.md.

Граница полномочий

VERIFIED и ACCEPTED_FOR_HANDOFF подтверждают качество результата, но не разрешают commit, push, merge, deploy, публикацию, удаление, установку зависимостей, работу с секретами или другие действия, требующие отдельного разрешения.