Автономные миссии

Name: Mockarty
Author: Mockarty

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

Про URL в примерах: адресом Mockarty в примерах служит localhost:5770. Если ваш экземпляр работает на другом сервере, замените адрес на реальный.

Раздел доступен на тарифах, включающих возможности ИИ-агента. Если пункт меню не виден — эта функция не входит в ваш текущий тариф.

Что такое миссия

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

У миссии всегда видно:

состояние — в очереди, идёт, на паузе, ждёт данных, ждёт согласования, выполнена, упала, отменена;
источник — интерфейс, агент, расписание, очередь сообщений, задача от другой системы;
продукт и сервис — чью работу она делает;
расход — сколько токенов потрачено и сколько осталось от бюджета.

Прикрепление оригиналов документов и макетов

В мастере новой миссии выберите продукт на шаге Контекст, затем файлы в поле Документы и дизайн-материалы. Можно прикрепить до 16 непустых файлов: изображения и PDF до 16 МиБ каждый, все файлы до 64 МиБ суммарно, текстовые документы до 64 КиБ суммарно. Файлы загружаются до запуска миссии. Если запуск завершился ошибкой, повтор с тем же продуктом и выбранными файлами использует успешные загрузки в открытом мастере.

Для анализа изображений выбранный профиль LLM должен поддерживать vision. Для PDF также требуется подключение к провайдеру с поддержкой PDF-входа. Передача оригиналов в OpenCode сама по себе не подтверждает, что выбранная модель умеет их интерпретировать; соответствие макету нужно проверить независимой приёмкой продукта до признания результата проверенным.

Для загрузки из скрипта отправьте один multipart file в POST /api/v1/missions/materials?namespace=default&productId=PRODUCT_ID. Ответ 201 содержит метаданные material и ссылку reference с полями kind, id, digest, revision. Включите эту ссылку в массив artifacts запроса POST /api/v1/missions с теми же пространством и продуктом. Не изменяйте возвращённые digest и revision.

curl --fail-with-body -H "Authorization: Bearer $MOCKARTY_API_TOKEN" \
  -F 'file=@design.png;type=image/png' \
  'http://localhost:5770/api/v1/missions/materials?namespace=default&productId=PRODUCT_ID'
mockarty-cli autonomy missions upload-material design.png --namespace default --product-id PRODUCT_ID

Go

result, err := client.CoderDelivery().UploadMissionMaterial(ctx, "default", productID, "design.png", "image/png", file)
// Передайте result.Reference в массив artifacts миссии.

Python

result = client.coder_delivery.upload_mission_material(product_id, "design.png", content, "image/png")
# Передайте result["reference"] в массив artifacts миссии.

Java

var result = client.coderDelivery().uploadMissionMaterial("default", productId, "design.png", content, "image/png");
// Передайте result.get("reference") в массив artifacts миссии.

Где выполняется автономная разработка

Задачи разработки выполняются в рабочем каталоге, выбранном для миссии. Они не
могут читать или менять файлы за его пределами, а инструмент разработки не
может сам себе выдать дополнительные права. Прикрепите нужные материалы до
запуска. Если миссии потребуется уточнение или выбор продукта, ответьте в её
диалоге.

История миссии

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

Продукт — это контекст страницы

Продукт выбирается в заголовке раздела, и от него зависит всё остальное: какие репозитории и креды берёт кодер, куда идёт доставка, какие расписания показаны, какой список сервисов доступен в фильтре.

Внутри продукта задача может относиться к сервису — одному репозиторию или компоненту из сотни. Это отдельное поле, а не отдельный продукт: сто репозиториев одной команды остаются одним продуктом, иначе список продуктов превращается в свалку.

Разбор: миссии без продукта

Когда задача приходит извне, Mockarty пытается понять, чья она: сначала по тому, чем прислана (токен, коннектор), затем по явно указанному продукту в сообщении, затем по правилам приёма продукта, затем по адресу репозитория или адресу сервиса. Если совпадений нет — миссия попадает в Разбор и ждёт человека. Если подошли сразу два продукта — Mockarty не выбирает наугад, а называет оба и просит решить.

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

Продукт должен уже существовать в текущем пространстве. UI, REST, SDK и MCP проверяют эту границу до изменения миссии или правила приёма; неизвестный идентификатор или идентификатор из другого пространства возвращает 404.

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

Режим	Что делает
спросить (по умолчанию)	Работу принимает, продукт спрашивает — миссия ждёт в Разборе.
создать	Заводит продукт по названию из сообщения.
строго	Отклоняет задачу, которую не удалось отнести к продукту.

Запуск миссии

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

Mockarty использует только доступные для этой миссии инструменты. Если с ними
невозможно составить план, вы увидите ошибку до начала работы. Если инструмент
временно недоступен, карточка миссии покажет задержку и время следующей
попытки.

Если во время проверки изменятся настройки продукта или пространства, Mockarty
попросит просмотреть их заново перед запуском.

Пауза, отмена и повтор шага

В карточке миссии можно поставить работу на паузу, продолжить или отменить её. Активный шаг можно повторить или пропустить. При отмене укажите причину, если другим участникам нужно понимать ваше решение. Миссию на паузе можно продолжить; Перезапустить создаёт новую попытку прерванного шага.

После отмены проверьте результат, прежде чем считать внешнюю работу остановленной. Mockarty может ждать подтверждения от раннера, обработчика очереди или системы развёртывания. В ответе различаются подтверждённые, отклонённые, ожидающие и неизвестные действия. Если executionBindingsAvailable=true, проверьте state каждого внешнего выполнения в executionBindings[]. Пустой список означает, что внешних запусков не было. Если доступность равна false, проверьте исполнителя напрямую. Запоздалый результат шага не перезапишет решение об отмене.

Для автоматизации через API и MCP

Клиент API или MCP может передать Idempotency-Key (в инструменте MCP — idempotency_key). После потерянного ответа повторите запрос с тем же ключом: Mockarty вернёт исходную квитанцию управления и не создаст вторую операторскую команду. Причина отмены или пропуска возвращается как control.reason при каждом точном повторе. Ответ миссии обрабатывается иначе: он остаётся в записи миссии и передаётся исполнителю, но не копируется в публичную квитанцию, события управления и метаданные аудита, чтобы возможно чувствительное значение не размножалось по доказательным поверхностям. Доставка повторяется автоматически только тогда, когда исполнитель умеет безопасно распознать тот же замысел. 202 с control.outcome=pending означает, что команда ещё проходит ограниченную доставку или локальное восстановление; повтор того же ключа безопасно читает и продвигает эту квитанцию. Однозначный отказ возвращается как 409. Если связь оборвалась после отправки и результат нельзя доказать, ответ будет 202 с control.outcome=ambiguous; Mockarty не угадывает и не повторяет потенциально опасную команду автоматически. Если Mockarty не смог завершить надёжное обновление после ограниченного восстановления, API вернёт 503 с control.outcome=interrupted; миссия останется защищённой от конфликтующих обновлений, а квитанция встанет в очередь аудита.

Отмена из автоматизации использует тот же надёжный контракт:

cURL

curl -X POST "$MOCKARTY_BASE_URL/api/v1/missions/$MISSION_ID/cancel" \
  -H "Authorization: Bearer $MOCKARTY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: incident-42-cancel" \
  -d '{"reason":"задача больше не актуальна"}'

CLI

mockarty-cli autonomy missions cancel "$MISSION_ID" \
  --reason "задача больше не актуальна" \
  --idempotency-key incident-42-cancel

Go

receipt, err := client.AutonomousMissions().Cancel(ctx, missionID,
    mockarty.MissionCancelRequest{
        Reason: "задача больше не актуальна", IdempotencyKey: "incident-42-cancel",
    })

Python

receipt = client.autonomous_missions.cancel(
    mission_id,
    MissionCancelRequest(
        reason="задача больше не актуальна",
        idempotency_key="incident-42-cancel",
    ),
)

Java

MissionControlResponse receipt = client.autonomousMissions().cancel(missionId,
    new MissionCancelRequest()
        .reason("задача больше не актуальна")
        .idempotencyKey("incident-42-cancel"));

Ответ миссии использует тот же идемпотентный ключ. Сам ответ намеренно отсутствует в control.reason:

cURL

curl -X POST "$MOCKARTY_BASE_URL/api/v1/missions/$MISSION_ID/answer" \
  -H "Authorization: Bearer $MOCKARTY_API_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: incident-42-answer" -d '{"answer":"используйте тестовую учётную запись"}'

CLI

mockarty-cli autonomy missions answer "$MISSION_ID" --answer "используйте тестовую учётную запись" \
  --idempotency-key incident-42-answer

Go

receipt, err := client.AutonomousMissions().Answer(ctx, missionID,
    mockarty.MissionAnswerRequest{Answer: "используйте тестовую учётную запись", IdempotencyKey: "incident-42-answer"})

Python

receipt = client.autonomous_missions.answer(mission_id,
    MissionAnswerRequest(answer="используйте тестовую учётную запись", idempotency_key="incident-42-answer"))

Java

MissionControlResponse receipt = client.autonomousMissions().answer(missionId,
    new MissionAnswerRequest().answer("используйте тестовую учётную запись").idempotencyKey("incident-42-answer"));

Для квитанции ambiguous или interrupted откройте карточку миссии и нажмите Сверить квитанцию. Сначала проверьте сам прогон в исполнителе, затем зафиксируйте Команда применена или Команда не применена и опишите доказательство. Во время такого восстановления Mockarty не отправляет исходную команду повторно — продолжается только локальное обновление под fence-защитой. То же действие доступно через POST /api/v1/missions/{id}/controls/{controlID}/resolve с телом {"resolution":"applied|refused","reason":"что проверили"} и MCP-инструмент mission_control_resolve. Требуется право deploy. Точный повтор идемпотентен, другое решение вернёт конфликт. После перезагрузки mission_get возвращает блокирующую публичную квитанцию control. Публичные квитанции используют стабильные коды ошибок и не раскрывают диагностику провайдера, транспорта или базы данных; подробности доступны администратору в защищённом журнале аудита и серверных логах.

Переносимые архивы миссий

Миссию в состоянии покоя можно экспортировать вместе с её неизменяемым Brief и полным журналом, а затем восстановить в другом совместимом экземпляре Mockarty. Архив остаётся привязанным к исходным ID миссии и пространству; восстановление не меняет ни одну из этих границ полномочий. Миссии в очереди и в работе экспортировать нельзя. Отсутствующий неизменяемый Brief, разрыв журнала, изменённый digest или любой конфликт идентичности отклоняются без частичного восстановления. Точный повтор того же архива безопасен и возвращает created=false. Крупные артефакты остаются ссылками по идентичности и в архив не копируются.

mockarty-cli autonomy missions archive export "$MISSION_ID" --file mission.mockarty-archive.json
mockarty-cli autonomy missions archive restore --file mission.mockarty-archive.json

Соответствующие вызовы SDK: ExportArchive / RestoreArchive в Go, export_archive / restore_archive в Python и exportArchive / restoreArchive в Java. Файл содержит метаданные миссии и payload журнала; защищайте его как эксплуатационное свидетельство.

Повторы инструментов с внешними эффектами

Для надёжных задач агента Mockarty сохраняет квитанцию исполнения до запуска инструмента. Если завершённый вызов повторно встретился после перезапуска, Mockarty вернёт сохранённый результат и не запустит инструмент второй раз. Инструмент с поддержкой дедупликации получает тот же ключ идемпотентности при неопределённом повторе. Безопасные операции чтения можно повторять как обычно.

Mockarty не может в одиночку сделать произвольный внешний сервис exactly-once. Если инструмент не поддерживает дедупликацию, а сервер остановился после отправки действия, но до сохранения результата, результат шага начинается с ПРЕДУПРЕЖДЕНИЯ О ДОСТАВКЕ. Действие уже могло выполниться, а восстановление — применить его ещё раз. Перед ручным повтором проверьте целевую систему. ПРЕДУПРЕЖДЕНИЕ О НАДЁЖНОСТИ означает, что саму квитанцию результата сохранить не удалось: автоматический повтор небезопасен до сверки целевой системы. Эти предупреждения остаются в ходе миссии и видны после перезапуска.

Когда миссия ждёт вас

Два состояния означают, что дальше без человека нельзя, и оба решаются прямо в карточке.

Ждёт данных. Миссия задала вопрос — например, просит тестовый счёт или доступ. Кнопка Ответить сначала сохраняет надёжную команду, затем передаёт ответ движку; работа продолжается только после подтверждения движка. Повтор с тем же идемпотентным ключом возвращает исходную квитанцию и не отправляет второй ответ. Ответ хранится в записи миссии, но не копируется в публичную квитанцию и метаданные аудита.

Ждёт согласования. Миссия дошла до шага, который требует решения человека (например, выкладка). Кнопки Согласовать и Отказать; при отказе стоит указать причину — она останется в журнале миссии. Согласование доступно тем, у кого есть право на доставку.

Счётчик Ждут вас в шапке показывает все такие миссии; клик по нему фильтрует список.

Что миссия делала и что оставила

Карточка миссии отвечает не только «что происходит», но и «почему так вышло».

Ход выполнения — шаги, которые сделал движок: что он попробовал, чем это кончилось, сколько токенов стоило и ссылка на первоисточник шага. Упавший шаг помечен — с него начинают разбор. Если шаг был вопросом, рядом стоит ответ человека: «спросил X → ответили Y» читается только вместе.

Что осталось после миссии — созданные моки, коллекции, тест-кейсы, отчёты, найденные аномалии, открытый merge request, результат доставки. Это превращает «выполнено» из утверждения в проверяемый факт и связывает прогон с сущностями продукта.

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

Стратегии выполнения

Спросить — тестировщик показывает план и ждёт вас; кодер останавливается на уточняющих вопросах и перед выкладкой. Так по умолчанию идут миссии, запущенные в интерфейсе: вы рядом и видите, что происходит.

Сквозная — миссия делает всё сама, без остановок. Так по умолчанию идёт работа, пришедшая извне: за ней обычно стоит система, а не человек, и ждать ответа не от кого.

Только разведка — миссия смотрит и рассказывает, ничего не меняя. Кодеру такая стратегия недоступна: он существует, чтобы менять код, и миссия с узлом кодера в разведке отказывается запускаться со внятной причиной — это честнее, чем сделать правки, о которых не просили.

Ограничения выполнения кодера

Страница кодера и раздел автономных миссий используют одно окно запуска. В нём вместе находятся продукт, репозиторий, бюджеты, порядки работы команды и ограничения выполнения — задача не становится менее безопасной из-за того, из какого меню её запустили.

Максимум попыток кодера — от 1 до 20 с учётом первой попытки; по умолчанию 5. Неудачная работа повторяется с паузой между попытками и останавливается на выбранном лимите; отмена и срок миссии прекращают цепочку до отправки новой попытки.
Глубина проверки может наследоваться от продукта, запускать только кодер (fast) или добавлять профильную проверку (thorough). Неизвестное значение отклоняется, а не молча меняет выбранный режим.
Цель доставки необязательна и должна совпадать с целью, настроенной у выбранного продукта. Оставьте поле пустым, чтобы собрать и проверить без выкладки. Защищённые цели по-прежнему требуют заданного для них согласования.

Если пользователю и пространству доступен модуль Processing, миссия кодера может пройти аналитико-архитектурный этап до реализации. Без Processing кодер по-прежнему разбивает и выполняет задачу, но не получает эту отдельно лицензируемую возможность.

Порядки работы команды

Раздел поставляется с готовыми порядками работы для четырёх ролей: аналитик (требование с проверяемыми критериями, оценка того, что сломается), архитектор (запись решения, проектирование от контракта), разработчик (правка, доведённая до доказательства; разбор merge request), тестировщик (баг → постоянный регрессионный кейс; готовность релиза по пяти пунктам) и общий для всех — не докладывать «сделано» без наблюдения, подтверждающего заявленное.

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

Какой моделью что работает

Вкладка Мощности отвечает и на этот вопрос: у каждого узла миссии — своя модель, отдельной строкой назначается модель проверки курса и модели внутренних шагов кодера (разбор задачи, приёмка, разбор merge request, разработка на раннере). Не назначено — работает модель по умолчанию, поэтому из коробки всё работает и без единой настройки.

Чем кодер собирает и проверяет

Кодер работает в контейнере, и в нём с самого начала есть рабочий минимум трёх самых частых стеков — чтобы он мог не только править файлы, но и собрать и проверить сделанное:

Go — компилятор целиком: сборка, тесты, go vet;
Python 3 — интерпретатор, pip и venv;
Node — фронтенд и npm-инструменты;
сборочные инструменты — make, компиляторы C/C++ (без них не собираются нативные модули Python и часть Go-зависимостей);
настоящий браузер — кодер открывает сделанную страницу, читает консоль, нажимает кнопки и убеждается, что работает именно то, что он написал;
повседневное окружение — git, curl, jq, ripgrep, unzip, rsync, SSH-клиент и kubectl.

В разделе Мощности карточки раннера перечислены доступные ему инструменты. Если их нет, карточка показывает предупреждение «нечем собирать». Проверьте это перед назначением задачи разработки.

Своего стека нет в списке? Добавьте его слоем поверх образа — базовый образ намеренно не тащит JDK, .NET, Rust и PHP: каждый из них добавляет сотни мегабайт ради части задач.

FROM mockarty/coder-runner:latest
USER root
RUN apt-get update \
    && apt-get install -y --no-install-recommends openjdk-21-jdk maven \
    && rm -rf /var/lib/apt/lists/*
USER coder

Соберите такой образ под своим именем и укажите его в развёртывании раннера. Новые инструменты появятся в объявлении сами — раннер проверяет окружение при запуске, отдельной настройки не нужно.

Что кодер уже знает о вашем стеке

Перед первой правкой кодер читает сам репозиторий — go.mod, package.json, pyproject.toml, pom.xml или build.gradle в корне и на один уровень ниже — и берёт подходящий инженерный плейбук: Go, бэкенд на Node/TypeScript, Python (FastAPI, Django), Java/Spring или веб-фреймворк интерфейса (React/Next, Vue/Nuxt, Svelte, Angular). Монорепозиторий с Go-API и React-фронтендом получает оба. Каждый плейбук — та планка, которую ждёт на ревью старший инженер этого стека: обработка ошибок, проверка входных данных на границе, слои, транзакции, тесты, падающие без правки, и собственные линтеры и команды тестов стека. Если в репозитории есть интерфейс, кодер держит и фронтовую планку — доступность с клавиатуры и для скринридеров, контраст в обеих темах, все состояния интерактивных элементов, адаптивность вплоть до ширины телефона — и правила текста для кнопок, ошибок и пустых состояний.

Ваши договорённости важнее: AGENTS.md, CLAUDE.md или CONTRIBUTING.md в репозитории и настроенные линтеры перекрывают плейбук там, где расходятся. В ваш репозиторий ничего не записывается: плейбуки живут в рабочей копии, в которой трудится кодер, и в коммиты не попадают.

Насколько тщательно работает кодер

У продукта есть выбор: быстро — работает только кодер, или тщательно — к каждой подзадаче подключаются специалисты (ревьюер, дизайнер интерфейсов), и в задание добавляется наставление, как ими пользоваться. Тщательный режим окупается на рискованных правках и лишний на однострочных, поэтому выбор живёт у продукта, а не включается на всю установку.

Не выбрано — работает так, как настроен раннер. Это значит, что из коробки всё работает и без этой настройки.

Идёт ли миссия туда

Раздел сам показывает, когда с прогоном что-то не так: миссия повторяет один и тот же шаг, подряд идут неудачи, бюджет расходуется без единого следа, миссия числится идущей и давно ничего не делала. Такие поводы видны в карточке сверху — заметить их надо раньше, чем кончится бюджет. Работу они не останавливают: решение остаётся за вами.

Эти признаки видят форму работы, но не её смысл. Миссия может бодро идти шаг за шагом — и заниматься не тем, о чём её просили. Для этого есть кнопка Проверить курс: модель читает цель, порядок работы, созданное и последние шаги и отвечает, делает ли миссия заявленное. Ответ — «Курс подтверждён» или «Курс под вопросом» с конкретными поводами — остаётся в карточке, поэтому его видит и следующий человек, и агент.

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

Узел цепочки можно перезапустить или пропустить — команда уходит в движок, который ведёт работу. Пропустить можно только активный узел: команда для будущего узла никогда не остановит текущую попытку. Если движок так не умеет (например, автономный тестировщик выбирает проверки сам), раздел скажет об этом прямо, а не сделает вид, что пропустил.

Если продукт не отвечает

Миссия, которой назвали адрес продукта, сначала проверяет, что по этому адресу кто-то есть, и только потом начинает работу. Проверка терпелива к развёртыванию, которое ещё поднимается: несколько попыток с паузами, около половины минуты в сумме.

Не ответил — миссия встаёт и спрашивает, а не проверяет. В карточке появляется вопрос с адресом и дословной причиной («connection refused», «connection timed out»), бюджет при этом не тратится: ноль токенов, ноль шагов. Так и должно быть: недоступный продукт — это не заключение о его качестве, а повод дать рабочий адрес или починить развёртывание.

Ответить можно там же, в карточке. Если в ответе есть адрес — «поднял заново, проверяй https://stage.example» — он становится новой целью миссии, и работа продолжается с него. Без этого ответ остался бы словами, а следующий шаг снова пошёл бы на мёртвый адрес.

Адрес берётся из задачи (поле productUrl или ссылка product_url), а если миссия привязана к продукту — из его адресов в каталоге. Миссия без адреса — например, про уже созданные тест-кейсы — проверку доступности не проходит и не ждёт: ей нечего открывать.

Проверка от имени ограниченной учётной записи

Некоторые проверки имеют смысл только от имени конкретного пользователя: «роль только для чтения должна получать понятный отказ», «этот релиз ничего не меняет». Дайте миссии саму учётную запись, а не описывайте её в цели.

Положите токен учётной записи в хранилище секретов.
Создайте подключение, у которого endpoint — это продукт, политика цели покрывает его пути и методы, а в allowedOperationIds есть <адаптер>.target_read и <адаптер>.target_write (например, shop.target_read, shop.target_write).
Отправьте задачу с адресом продукта и ссылкой restricted_connection_ref на точную ревизию:

{
  "goal": "Учётная запись только для чтения. Проверь, что интерфейс понятно отказывает в создании записей.",
  "autonomy": "auto",
  "options": ["ui"],
  "productUrl": "https://shop.example.com",
  "contextRefs": [{"kind": "restricted_connection_ref", "value": "shop-reader@1"}]
}

Что меняется для такой миссии:

Она обращается к продукту только от имени этой учётной записи. API-вызовы идут через инструмент target_request, а браузерная сессия открывается на продукте и действует от имени учётной записи — учётные данные подставляет Mockarty, и они не попадают ни к модели, ни к браузерному раннеру, ни в отчёт.
Каждый запрос к продукту оставляет квитанцию. Ответ 403 записывается как permission_denied и считается результатом, о котором нужно сообщить, а не сломанным инструментом. Запись — это настоящая попытка, поэтому миссию, которой запретили писать, можно проверить по её квитанциям: пыталась она или нет.
Инструменты, которые дошли бы до продукта иначе, — обычные HTTP-запросы, сохранённые UI-тесты, сканеры, нагрузка, делегирование другим агентам — ей недоступны.
Проверки, которые иначе ждали бы вашего согласования как разрушительные (безопасность, нагрузка), не останавливаются ради него: без своих движков предел их действий — запись в продукт от имени учётной записи.

Миссия отклоняется до начала работы, с причиной в карточке, если ссылка не разрешается в эту точную ревизию, если подключение не разрешает target_read, если адрес продукта не совпадает с endpoint подключения или если в задаче названо больше одной ограниченной учётной записи. Для браузерной части нужна веб-сессия на настоящем браузерном движке (Chromium, Firefox или WebKit); мобильные сессии и сохранённые состояния входа с ограниченной учётной записью не сочетаются.

Задачи от внешних систем

Миссия не обязана начинаться в интерфейсе. Её ставят: агент через MCP, соседняя система задачей A2A, сообщение в очереди (NATS, Kafka, RabbitMQ), вебхук трекера, расписание. Любая такая задача появляется в разделе сразу — с целью, источником, запланированным графом и бюджетом, — и дальше ведётся так же, как запущенная руками.

Обычный контракт начинается с цели: Mockarty планирует всю работу по формулировке задачи и разрешённому каталогу возможностей. Если задача ещё и перечисляет нужные проверки (options, например ["api", "security"]), каждая перечисленная проверка, доступная задаче, входит в план — планировщик может добавить свои, но не может выбросить заявленную. Перечисленные проверки не создают вторую систему миссий и не обходят общую власть планирования, доказательств и отмены.

Если цель сформулирована расплывчато, миссия сама спросит, чего ей не хватает, и встанет в ожидание — вопрос виден в карточке, ответ даётся там же.

Расписания

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

У расписания есть свой промпт: вы пишете, что именно сделать («прогнать оплату картой и возвраты, найти регресс после релиза»), и именно этот текст становится целью миссии. Кроме промпта задаются имя, расписание в формате cron (0 3 * * * — каждую ночь в три; поддерживаются и сокращения вида @daily) и, при необходимости, сервис. При срабатывании расписания Mockarty сам строит ход выполнения из цели; ведущий узел выбирать не нужно.

Сработавшее расписание становится обычной миссией с источником «Расписание» — утром она видна в общем списке рядом с остальными, с целью, запланированным графом и расходом. Пока предыдущий прогон расписания не закрыт, следующий не заводится: два одновременных выполнения одной задачи только мешают друг другу.

Конструктор workflow

Во вкладке Конструктор повторяемый workflow собирается как версионируемый граф шагов из каталога возможностей, проверяется пробным прогоном (возможности, подключения, секреты, верхняя граница стоимости) и публикуется неизменяемой версией. Публикация миссию не запускает. Пошагово: «Версионируемые определения процессов».

Триггеры и Знания

Вкладка «Триггеры» отвечает, что запускает здесь работу: расписания продукта (цель, cron, продукт — и проверка идёт сама), слушатели входящих и честный счёт, откуда миссии реально пришли за последние 7 дней, — по записям, а не по конфигурации. Кнопка «Настроить подключения» открывает редактор коннекторов прямо в разделе миссий. В нём можно создать входящие коннекторы NATS, Kafka, RabbitMQ, HTTP, Telegram, Slack и триггера задач, а также исходящие вебхуки; изменить настройки, выключить или снова включить их, удалить. Тип и направление после создания не меняются. Выключенные коннекторы остаются в списке для повторного включения. Сохранённый секрет и адрес получателя редактор не показывает: при редактировании оставьте поле пустым, чтобы сохранить прежнее значение.

Входящий HTTP-коннектор использует HMAC-секрет и адрес /api/v1/intake/{id}, который можно скопировать. Telegram использует секретный токен вебхука и адрес /api/v1/public/intake/{id}/telegram, Slack — секрет подписи и адрес /api/v1/public/intake/{id}/slack. Редактор даёт скопировать соответствующий адрес. NATS, Kafka и RabbitMQ используют настройки и реквизиты брокера; этот секрет вебхука они не проверяют. Для триггера задач нужно указать правило по статусу или исполнителю; он реагирует на авторизованный вебхук задачи. Для коннекторов без собственного адреса вебхука копируется ID. API коннекторов позволяет авторизованному читателю получить выключенные записи через GET /api/v1/autotester/connectors?include_disabled=true; без флага список по-прежнему содержит только включённые. Ответы списка и карточки не раскрывают сохранённые секреты.

Исходящему вебхуку нужны полный HTTP(S)-адрес получателя и секрет подписи. Он отправляет значимые события миссии; включайте «Отправлять каждое событие прогресса» только если получателю нужны пошаговые обновления. Получатель может проверить X-Intake-Signature по телу JSON. Сервер может отклонить адрес в локальной или частной сети по сетевой политике.

Карточка коннектора показывает только известные несекретные поля настройки. Неизвестные значения и адреса брокеров, которые могут содержать учётные данные, скрываются; оставьте скрытое поле пустым, чтобы сохранить прежнее значение, либо введите новое значение вместо него. Ответ карточки содержит updated_at; передайте его как expected_updated_at в PUT, чтобы защитить изменения из ранее открытого окна. Если другой редактор изменил коннектор раньше, сохранение вернёт 409: закройте карточку и откройте её снова, чтобы загрузить актуальные настройки. Удалённый во время редактирования коннектор вернёт 404 и не будет создан заново.

Вкладка «Знания» — что продукт знает и чему научилась установка. Факты продукта (пример запроса, инвариант предметной области, известная проблема, заметка об окружении) добавляют люди и агенты — их читает контекст, с которого стартует автономный тестировщик; устаревший факт удаляется — следующие прогоны его больше не увидят. Уроки ищутся по смыслу по опыту всей установки. Агенту то же самое доступно как qa_product_facts_list / qa_product_facts_add / qa_product_fact_delete, experience_search и mission_triggers.

Инциденты выкаток

Когда выкаченное миссией ведёт себя не так, заведите инцидент, а не ветку в чате. Откройте вкладку Инциденты, выберите продукт в заголовке и нажмите Открыть инцидент. Выберите миссию; прогон выкатки указывать необязательно. Артефакт, окружение и продукт берутся из этой выкатки, поэтому инцидент всегда указывает ровно на то, что выехало. У миссии, которая ничего не выкатывала, инцидента быть не может.

В инциденте собираются гипотезы — возможные причины: короткий код (db_timeout, config_drift) и объяснение, почему её подозревают. Гипотезы предлагают и люди, и агенты.

Приложить свидетельство — подкрепить гипотезу и отметить, подтверждает ли свидетельство её, опровергает или даёт контекст. Способа два:

Ссылка на материал — где лежит свидетельство: run://<идентификатор прогона>, report://…, log://…, metric://…, trace://…, event://…, artifact://… или deployment://…. Работает всегда, в том числе без стека наблюдаемости.
Запрос к наблюдаемости — если для пространства имён настроены источники наблюдаемости (см. раздел «Наблюдение за развёрнутым» в Автономном кодере), выберите источник, что читать и окно (по умолчанию 15 минут). Запрос сам привязывается к миссии, выкатке и артефакту инцидента, а в инциденте сохраняется только отпечаток результата. Для этого способа нужен модуль «Надёжность».

Сделать вывод закрывает гипотезу как подтверждённую, опровергнутую или неопределённую с обоснованием. Любой вывод требует приложенного свидетельства: для «подтверждена» — подтверждающего, для «опровергнута» — опровергающего, для «не определено» — любого. Вывод окончательный, и сделать его может только вошедший в систему человек: вызов с API-токеном отклоняется ответом 403 human_conclusion_required — агент помогает сузить причину, а решение остаётся за человеком.

Каждое изменение сверяется с той версией инцидента, которую вы видели. Если инцидент изменили, пока окно было открыто, Mockarty отклонит изменение (409 revision_conflict), обновит список и попросит повторить.

cURL

# Сначала прочитайте инцидент: его "revision" передаётся в expectedRevision.
curl "$MOCKARTY_BASE_URL/api/v1/missions/incidents/$INCIDENT_ID?projectId=$PRODUCT_ID" \
  -H "Authorization: Bearer $MOCKARTY_API_KEY"

curl -X POST "$MOCKARTY_BASE_URL/api/v1/missions/incidents/$INCIDENT_ID/hypotheses" \
  -H "Authorization: Bearer $MOCKARTY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"projectId":"'"$PRODUCT_ID"'","code":"db_timeout","reason":"p99 вырос втрое после релиза",
       "idempotencyKey":"inc-42-db-timeout","expectedRevision":3}'

GET /api/v1/missions/incidents?projectId=… возвращает инциденты продукта, новые первыми; чтобы получить следующую страницу, передайте полученный nextCursor как cursor. POST /api/v1/missions/incidents с projectId, missionId и необязательным deploymentRunId открывает инцидент. POST /api/v1/missions/incidents/{incidentId}/hypotheses/{hypothesisId}/evidence прикладывает свидетельство: либо sourceRef и kind (log, metric, trace, event или report), либо source, queryKind и необязательные expression и windowMinutes; relation — supports, refutes или context. Если источник не настроен, ответ — 409 observability_unavailable. Если настроенный источник не смог вернуть допустимое свидетельство, ответ — 503 observability_query_failed: проверьте источник и повторите попытку. Повтор запроса с тем же idempotencyKey возвращает первый ответ, а не создаёт дубль.

Если запись инцидента не прошла проверку целостности, API возвращает 500 incident_integrity_error. Обратитесь к администратору: изменение запроса не исправит запись.

Метрики и бюджеты

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

Откройте конкретную миссию и выберите «Экономика», чтобы увидеть её точный срез неизменяемого журнала учёта: вызовы и токены модели, кэшированный вход, физические ресурсы раннера и инструментов, события без назначенной цены и списанную сумму по каждой валюте. Выбранные потолки бюджета остаются рядом с фактическим расходом, но не смешиваются с ним. Если хранилище учёта недоступно, карточка прямо говорит, что фактический расход недоступен, а не показывает нулевые траты.

Выбранность бюджета считается по незавершённой работе — это ответ на вопрос «упрёмся ли мы в лимит», а не история трат.

Те же разрезы доступны как источники данных для дашбордов — в конструкторе виджетов они собраны в категории Автономные миссии. Так метрики автономной работы можно положить на общий дашборд рядом с остальными показателями.

То же самое из агента

Всё, что делает человек на странице, доступно ИИ-агенту через инструменты Mockarty:

missions_list — список и счётчики одним вызовом; productId=none вместе с состоянием «ждёт данных» — это очередь Разбора;
mission_get — карточка миссии с цепочкой;
mission_start — запуск;
mission_control — пауза, продолжение, отмена, ответ на вопрос миссии и решение на согласовании; для паузы, продолжения, отмены или решения используйте стабильный idempotency_key, если агент может повторить запрос после потери ответа;
mission_step — перезапуск или пропуск одного узла с такой же необязательной квитанцией idempotency_key;
mission_control_resolve — после прямой проверки исполнителя безопасно разрешить квитанцию ambiguous или interrupted как applied либо refused, не повторяя исходную команду;
attention_queue — что требует человека прямо сейчас, одним вызовом: миссии, ждущие ответа или согласования, бегущие с аномалиями и упавшие за последние сутки — свежие выше. Та же очередь, которую человек видит вверху страницы миссий: человек и агент разбирают один список;
incidents_list / incident_get / incident_open / incident_propose_hypothesis / incident_attach_evidence — журнал инцидентов выкаток: читать инциденты, открыть инцидент на выкатку миссии, предложить причину и подкрепить её свидетельством. Вывод по гипотезе делает человек, поэтому инструмента для него нет;
mission_review — проверка курса: делает ли миссия то, о чём её просили;
mission_bind — привязка к продукту, при желании с запоминанием правила;
qa_cadence_set / qa_cadence_list — расписания продукта, включая их промпт;
capabilities_list — один каталог всего, что умеет этот инстанс: компоненты миссий, персоны и наборы инструментов агентов, движки раннеров, плагины и WASM-расширения. Каждый версионированный descriptor содержит точный источник, состояние доверия и изоляции, policy побочных эффектов и границ данных, envelope ресурсов/стоимости, схемы, привязку executor/health и вашу доступность с точной причиной блокировки. Общий планировщик использует эту authority автоматически; оператор и автор расширения могут посмотреть каталог, чтобы понять, почему возможность выбрана или заблокирована. Тот же список доступен как GET /api/v1/capabilities и как ListCapabilities / list_capabilities / listCapabilities в Go, Python и Java SDK;
mission_settings_effective — какие настройки автономности выбраны и почему: каждая строка содержит значение, задавший его слой (миссия → продукт → пространство имён → установка → поставка) и runtimeApplied. Политика охранника и окно прогона фиксируются при старте миссии; встроенное окно равно 480 минутам. Хранение журнала устроено иначе: это живая операторская политика пространства/установки, которую использует планировщик очистки; она не фиксируется в одной миссии, а уровни продукта и миссии к ней не применяются. Настройте её в Автономные миссии → Лимиты и настройки → Хранение свидетельств миссий, оставьте поле пустым для наследования либо автоматизируйте через mockarty-cli autonomy settings get|set и NamespaceSettings SDK для Go/Python/Java. Таймлайн и история завершённых миссий используют срок событий, подробные payload — более короткий срок и никогда не переживают событие. Активная юридическая блокировка всегда имеет приоритет. Переменные запуска MOCKARTY_MISSION_EVENT_RETENTION_DAYS и MOCKARTY_MISSION_PAYLOAD_RETENTION_DAYS остаются встроенным значением установки. Тот же ответ доступен как GET /api/v1/missions/settings/effective. Сбой чтения хранилища возвращает 503 с кодом mission_settings_unavailable, а очистка останавливается без догадок.

mission_start и mission_bind принимают только продукт, который сейчас существует в том же пространстве имён. Неизвестный или чужой продукт возвращает 404. Если authority продуктов нельзя прочитать, инструменты возвращают повторяемый ответ 503 product_authority_unavailable: повторите неизменённый запрос. Повторный mission_start с тем же originRef возвращает уже зафиксированную миссию, даже если её прежний продукт удалили после потери первого ответа.

Автоматизация безопасности и хранения пространства

Эндпоинт по-прежнему заменяет старые поля автономности, бюджета и знаний, поэтому перед их изменением прочитайте текущий документ. Стена прогона и поля retention добавочные: пропущенное поле сохраняет override, а явный null очищает его и включает наследование. Стена принимает 1..20160 минут и без override наследует встроенные 480 минут. Retention принимает целые значения от 1 до 3650 дней, причём срок подробных payload не может превышать срок таймлайна. Размер запроса ограничен 256 КиБ, число источников знаний — 128, тип — 64 байтами, значение — 4096 байтами; неполные строки и отрицательные бюджеты отклоняются, а не исправляются молча. CLI и clear-методы SDK отправляют null только по явной команде наследовать.

GET /api/v1/autotester/settings возвращает строгий ETag. Передавайте его в If-Match при сохранении, чтобы устаревший редактор не перезаписал новую политику; UI, CLI и SDK делают это автоматически. Устаревшая запись получает 412: загрузите и проверьте новые значения. Каждый PUT также принимает Idempotency-Key; после потерянного ответа повторите тот же ключ и точно то же тело. Другое тело с тем же ключом получает 409. Ответ 503 с Policy-Applied: true и Audit-Pending: true означает, что настройки уже сохранены, а центральная аудит-запись надёжно поставлена в очередь — повтор с тем же ключом безопасен.

mockarty-cli autonomy settings get --namespace engineering
mockarty-cli autonomy settings set --namespace engineering --run-window-minutes 90 --event-days 365 --payload-days 30 --request-id safety-change-2026-08-25
mockarty-cli autonomy settings set --namespace engineering --inherit-payload
mockarty-cli autonomy settings set --namespace engineering --inherit-run-window

current, _ := client.NamespaceSettings().GetAutonomySettings(ctx)
events, payloads, window := 365, 30, 90
current.JournalEventRetentionDays = &events
current.JournalPayloadRetentionDays = &payloads
current.RunWindowMinutes = &window
saved, err := client.NamespaceSettings().SaveAutonomySettingsWithOptions(ctx, current,
    mockarty.AutonomySettingsSaveOptions{RequestID: "retention-change-2026-08-23"})
// Чтобы явно обнулить ненулевой бюджет, также задайте ReplaceDefaultBudget: true.
// Явно наследовать политику payload от установки:
saved, err = client.NamespaceSettings().ClearAutonomyRetention(ctx, false, true)
saved, err = client.NamespaceSettings().ClearAutonomyRunWindow(ctx, mockarty.AutonomySettingsSaveOptions{})

current = client.namespace_settings.get_autonomy_settings()
current.update(journalEventRetentionDays=365, journalPayloadRetentionDays=30, runWindowMinutes=90)
saved = client.namespace_settings.save_autonomy_settings(
    current, request_id="retention-change-2026-08-23")
# Явно наследовать политику payload от установки:
saved = client.namespace_settings.clear_autonomy_retention(clear_payload=True)
saved = client.namespace_settings.clear_autonomy_run_window()

AutonomyNamespaceSettings current = client.namespaceSettings().getAutonomySettings();
current.journalEventRetentionDays(365).journalPayloadRetentionDays(30).runWindowMinutes(90);
AutonomyNamespaceSettings saved = client.namespaceSettings()
    .saveAutonomySettings(current, "retention-change-2026-08-23");
// Явно наследовать политику payload от установки:
saved = client.namespaceSettings().clearAutonomyRetention(false, true);
saved = client.namespaceSettings().clearAutonomyRunWindow(null);

Частые вопросы

Миссия находится «в очереди». Сначала откройте карточку. Предупреждение о доставке означает, что исполнитель временно недоступен и Mockarty повторяет запуск автоматически; там указано время следующей попытки. Если предупреждения нет, проверьте лицензию компонента и работу соответствующего сервиса. Новая миссия без исполнителя отклоняется сразу.

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

Миссия попала не в тот продукт. Нажмите Привязать и выберите правильный. Если такие сообщения приходят регулярно — снимите галочку запоминания правила у неверного продукта в его настройках приёма и поставьте у правильного.

Смежные разделы

Автономный тестировщик — как устроен автономный тестировщик и его уровни автономности.
Автономный кодер — флот раннеров, очередь заданий и настройки доставки продукта.
Дашборды — куда положить метрики автономной работы.
Вердикты качества — из чего состоит вердикт прогона и как человек отзывает или переопределяет его.