Приёмка

Приёмка отделяет «исполнитель считает, что готово» от «проверено и принято». Исполнитель сдаёт отчёт, и задача получает статус REPORTED. Принятой она становится, только когда кто-то другой проверил результат и подтвердил это вызовом accept. Автор кода не принимает собственную работу: это главное правило приёмки в Actari.

ОтчётКопировать ссылку на раздел

Отчёт — это доказательство, а не пересказ. Хороший отчёт содержит:

• команды, которые исполнитель запускал, и их вывод;
• список изменённых файлов;
• отдельный раздел «Находки» о том, что исполнитель заметил и не тронул;
• заметку, что он не проверял, если такое есть.

submit_report { task_id: "shop/2026-11-03-csv-export",
                report: "Было красным → стало зелёным: …\nИзменены: …\nНаходки: …",
                duration_minutes: 42 }

Необязательный duration_minutes (от 1 до 1440) передаёт облаку, сколько заняла работа. Что именно должно быть в отчёте в вашем проекте, определяет политика: её правило для отчёта встроено в описание инструмента.

Кто проверяетКопировать ссылку на раздел

Проверяющий не должен знать ничего, кроме номера задачи, критериев и команд проверки. В Claude Code это отдельный субагент без контекста автора: он читает отчёт, смотрит изменения построчно, сам запускает проверки и отвечает вердиктом фиксированной формы:

verdict: accept | rework | failed
evidence: какие команды запускал и что получилось
architecture: нет | проверка недоступна — причина | список расхождений
findings: что не так или вызывает сомнение, по одной строке

Вердикт записывается как заметка acceptance: <номер задачи>, чтобы его можно было перечитать. Если в клиенте нет субагентов, агент показывает вам отчёт и подтверждения и принимает задачу, только когда вы скажете «ок». Принять задачу потому, что собственный прогон прошёл, или позвать «проверяющего» с тем же контекстом — это не приёмка.

Если пространство ведёт карту системы, перед чтением изменений проверяющий вызывает architecture_check { task_id }: он возвращает действующие решения (ADR) затронутых компонентов и подсказки, что искать в изменениях. Изменение, которое противоречит действующему ADR без нового ADR-замены, считается находкой и блокирует приёмку, если только задача не просила пересмотреть то решение.

Три исходаКопировать ссылку на раздел

Принять. Прогон зелёный, блокирующих находок нет:

accept { task_id: "shop/2026-11-03-csv-export",
         evidence: "Коммит 4f3e8f2, полный прогон: 312 прошли, 0 упали" }

Параметр outcome по умолчанию accepted; значение accepted-with-fixes отмечает, что принято с исправлениями. Если у задачи есть намерение из облака, перед приёмкой стоит вызвать intent_status: человек мог отменить его или поменять критерии, и тогда сервер откажет.

Вернуть на доработку. Есть блокирующая находка или красный прогон:

request_rework { task_id: "shop/2026-11-03-csv-export",
                 reason: "Файл не открывается в Excel: нет BOM (export.ts:41)" }

Статус становится REWORK, дальше задача снова передаётся исполнителю вызовом delegate, он исправляет и сдаёт новый отчёт, а проверяет его уже новый проверяющий. После второго возврата или провала на одной задаче агент не крутит цикл дальше: он закрывает задачу и спрашивает вас, что делать.

Закрыть неудачей. Задание невыполнимо в нынешнем виде:

mark_failed { task_id: "shop/2026-11-03-csv-export",
              reason: "Нужна выгрузка потоком, текущая библиотека не умеет" }

mark_failed работает из статусов DELEGATED, REPORTED и REWORK. Дальше обычно заводят новую задачу и связывают её со старой через link_tasks.

Доказательство при приёмкеКопировать ссылку на раздел

Параметр evidence — то, чем подтверждена приёмка: хэш коммита, ссылка на прогон CI, вывод тестов. Обязательность задаёт политика. При политике «Приёмка по доказательству» или «Полная дисциплина» вызов accept без evidence сервер отклоняет. В облаке доказательство показывается рядом с принятой карточкой на доске.

Что видно в облакеКопировать ссылку на раздел

Пока работа не проверена, карточка стоит в колонке «Отчёт не проверен», а задача подписана «отчёт сдан — не проверено» и выделена предупреждающим цветом. После приёмки карточка уходит в «Сделано» (или «Принято», если включён учёт выпусков), подпись становится «проверено и принято» и меняет цвет на успешный. Это сделано намеренно: заявленное нельзя спутать с подтверждённым.

Расход токеновКопировать ссылку на раздел

После работы исполнителя и проверяющего агент записывает расход вызовом log_usage с ролью executor или acceptance. Сервер сам находит токены по номеру сессии клиента, цифры агент не переписывает. На статус задачи этот вызов не влияет.

Что дальшеКопировать ссылку на раздел

• Что происходит с принятым: Выпуски.
• Какие правила приёмки можно включить: Политика проекта.
• Как приёмка встроена в цикл: Скиллы цикла.