# Приёмка

Как заявленное исполнителем становится принятым: отчёт, независимая проверка и вердикт.

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

## Отчёт

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

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

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

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

## Кто проверяет

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

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

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

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

## Три исхода

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

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

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

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

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

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

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

```text
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`. Сервер сам находит токены по номеру сессии клиента, цифры агент не переписывает. На статус задачи этот вызов не влияет.

## Что дальше

- Что происходит с принятым: [Выпуски](/docs/concepts/releases).
- Какие правила приёмки можно включить: [Политика проекта](/docs/agents/policy).
- Как приёмка встроена в цикл: [Скиллы цикла](/docs/agents/skills).