Вердикты качества

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

Что такое вердикт

Вердикт относится к одному прогону и идентифицируется его task id. Он несёт:

Исход — pass, fail или could_not_verify. Последнее — настоящий
ответ, а не пожатие плечами: прогон не смог прийти к выводу (недоступный
продукт, исчерпанный бюджет) и говорит об этом вместо догадки.
Поверхности — каждая область, которую прогон должен был проверить, с
признаком ran (проверялась ли вообще), покрытием, глубиной, уверенностью и
найденными аномалиями. Поверхность с ran: false не трогали; её молчание —
не «пройдено». Покрытие вида 18/29 означает 18 успешных проверок из 29
выполненных; неуспешные проверки попадают в аномалии, а непроведённые — в
непокрытые пробелы.
Аномалии — у каждой серьёзность, воспроизведение и dedup_key, совпадающий
с дефектами из знаний о продукте, так что новую проблему можно отличить от
той, о которой уже сообщал прежний прогон.
Непокрытые пробелы — что не проверялось, с полем remedy: что реально
поможет — починить продукт или его окружение, повторить (временное или
бюджетное ограничение), ничего (проверка недоступна) или решение человека.
Запись жюри — версии рубрики и промпта, голосовавшие модели, сколько
критериев решено, сколько оспорено, сколько присяжных воздержалось, плюс
калиброванная уверенность.
Привязка приёмки — остаётся ли этот вердикт текущим для своего прогона
или отозван.

Блок conformance содержит исход по каждому критерию из acceptance[].
Описание требований в product_context или перечисление объектов в
conformance_target не создаёт отдельных критериев; без acceptance[]
блока conformance нет.

Критерий, у которого target — эндпоинт ({"kind":"endpoint","ref":"POST /api/orders"}),
оценивается только по проверкам этого эндпоинта. Если его никто не проверял —
например, потому что запись в этом прогоне отключена, — критерий помечается как
невычисленный, с причиной и подсказкой, что объявить, чтобы его измерили.
Находки по другим эндпоинтам его не проваливают.

Приёмка автоматическая

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

Чтение вердиктов

# Последние вердикты вашего пространства имён — по одной строке-заголовку
curl -H "X-API-Key: $MOCKARTY_API_KEY" \
  "http://localhost:5770/api/v1/quality/verdicts?limit=20"

# Один вердикт целиком
curl -H "X-API-Key: $MOCKARTY_API_KEY" \
  "http://localhost:5770/api/v1/quality/verdicts/<taskId>"

Список отвечает {"verdicts": [...], "namespace": "...", "count": N}; в каждой
строке taskId, outcome, qualityScore, notEvaluated, current,
bindingStatus, заголовок jury и confidenceLowerBound. Если клиент прогона
объявил сборку, которую он тестировал, строка несёт ещё и
acceptedArtifactDigest — digest сборки, выведенный из коммита, чтобы
сравнить его с картиной деплоя (ниже), не открывая сам вердикт. Тел в списке
нет — читайте один вердикт, полный документ приходит под ключом verdict.
limit принимает 1–200 (по умолчанию 20); namespace по умолчанию —
пространство вызывающего.

Полный вердикт также содержит блок deployment — то же сравнение, что делает
отдельная ручка ниже, вычисленное на месте.

Этот вердикт — про то, что задеплоено?

Один запрос сравнивает сборку, за которую ручается вердикт, с кандидатом,
который сейчас задеплоен в окружение. Обе стороны — digest, выведенные из
исходного коммита, поэтому сравнение точное и не требует ручной работы:

curl -H "X-API-Key: $MOCKARTY_API_KEY" \
  "http://localhost:5770/api/v1/quality/verdicts/<taskId>/deployment?environment=staging"

В ответе state, acceptedDigest (из вердикта), deployedDigest (из
принятого деплой-прогона) и deploymentRunId:

exact — задеплоенный кандидат и есть та сборка, за которую ручается
вердикт;
different — задеплоено что-то другое; вердикт стоит читать как историю, а
не как описание живого окружения;
unknown — последний деплой ещё выполняется или его откат не подтверждён,
принятый деплой неизвестен, вердикт не объявлял сборку либо деплой-прогоны
не журналируются на этой установке.

environment необязателен: без него сравнение опирается на последний прогон
пространства, который мог изменить окружение. Если этот прогон принят, ответ
указывает его окружение.

Отзыв вердикта (`invalidate`)

Отзыв фиксирует, что вердикту больше нельзя доверять. Привязка прогона
переходит в состояние «отозван», с причиной и тем, кто отозвал. Он не
отменяет то, что внешний потребитель уже получил.

curl -X POST -H "X-API-Key: $MOCKARTY_API_KEY" -H "Content-Type: application/json" \
  -d '{"reason": "стенд был в середине деплоя во время прогона"}' \
  "http://localhost:5770/api/v1/quality/verdicts/<taskId>/invalidate"

Причина необязательна, но записывается; ответ называет новый status и
повторяет предупреждение о том, что потребитель не уведомлён.

Переопределение вердикта (`override`)

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

curl -X POST -H "X-API-Key: $MOCKARTY_API_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: review-2026-09-21-run-42" \
  -d '{"reason": "падающая проверка бьёт по флагу, выключенному в проде", "outcome": "pass", "expectedRevision": 1}' \
  "http://localhost:5770/api/v1/quality/verdicts/<taskId>/override"

reason обязателен — переопределение без причины не является решением,
которое кто-то сможет проверить.
outcome необязателен (pass, fail, could_not_verify) и по умолчанию
равен текущему исходу вердикта, так что причину можно приложить, не меняя
вывод.
expectedRevision необязателен и по умолчанию равен текущей ревизии;
передайте его, если читали вердикт раньше и хотите получить 409, когда
кто-то изменил его между делом.
Idempotency-Key делает повтор безопасным; без него ключ выводится
детерминированно. Ответ — {verdictId, namespace, revision, outcome, reason, replayed}; replayed: true значит, что ровно это переопределение уже было
записано и ничего нового не создано.

Кто что может

Для чтения вердиктов нужна аутентифицированная сессия или API-токен с доступом
к пространству имён. Для отзыва и переопределения нужен доступ на запись в
пространство имён вердикта; любой другой вызывающий получает 403. Каждый
отзыв и каждое переопределение попадают в журнал аудита с актором и причиной.
Вердикты относятся к модулю «Автономные миссии» и следуют его лицензии.

Для агентов

Чтение и переопределение доступны и как MCP-инструменты, так что ИИ-агент
может прочитать результат прогона прежде, чем действовать, и записать
курируемое решение:

quality_verdicts_list — строки-заголовки (limit), включая
acceptedArtifactDigest каждого прогона, объявившего сборку.
quality_verdict_get — полный документ по taskId, внутри — сравнение
deployment; читайте surfaces[].ran и uncovered[] раньше, чем балл.
aqc_override_verdict — taskId и reason обязательны, outcome и
expectedRevision необязательны, семантика та же, что у REST-вызова.

Отзыв (invalidate) доступен только через REST.

Связанные страницы

Автономные миссии
Автономный агент
Настройка администратора — журнал решений