Автономный кодер

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

Откройте Автономные миссии (/ui/missions?view=coder). Единый cockpit показывает миссии кодера вместе с мощностью раннеров, очередью задач, доказательствами, экономикой, знаниями и маршрутизацией моделей по компонентам.

Модуль закрыт возможностью A2A / Автономность. Одобрение деплоя и настройка доставки дополнительно требуют роль владельца или администратора в пространстве имён.

Ожидание раннера

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

Для push-раннеров регистрация и завершение задания запускают доставку.
Heartbeat также возобновляет доставку после перезапуска админа или исчерпания
окна диспетчеризации; это восстановление не гарантирует мгновенную выдачу.
Отказ одного раннера не мешает другому подходящему раннеру получать работу.
Неоднозначный исход доставки не считается доказательством, что выполнение не началось.

Слоты ограничивают задания, а не внутренних субагентов движка кодирования.

Проверить мощность

Вкладка Мощности показывает раннеры и текущую очередь заданий. Для скриптов
компактный ответ содержит runnerCount, onlineRunners, slots, busy и
queued выбранного пространства. Данные могут отставать на две секунды;
slots учитывает раннеры на связи. Отсутствие ответа означает, что мощность
неизвестна.

curl -H "Authorization: Bearer $MOCKARTY_API_TOKEN" \
  "$MOCKARTY/api/v1/coder/capacity?namespace=$NAMESPACE"

Если нужны недавние задания, используйте /api/v1/coder/jobs?limit=50 (1–100).
Без limit прежний ответ по-прежнему содержит полный список.

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

Нажмите Новая миссия и заполните:

• Цель миссии — простым языком, например: «Добавить REST-эндпоинт /health с информацией о сборке и тестами».
• URL git-репозитория — репозиторий, который кодер клонирует и в котором работает.
• Движок (необязательно) — движок кодинга на раннере (opencode по умолчанию).

Через MCP это один вызов:

{
  "tool": "coder_mission_start",
  "arguments": {
    "goal": "Добавить REST-эндпоинт /health с информацией о сборке и тестами",
    "repoUrl": "https://git.example.com/team/app.git",
    "issueKey": "APP-42"
  }
}

issueKey связывает миссию с задачей трекера: сообщения коммитов начинаются с ключа (например, APP-42: ...), панель задачи показывает миссию, а дашборд эффективности сравнивает оценку задачи с фактическим временем работы миссии. Mockarty не добавляет команду автозакрытия в каждый коммит подзадачи: момент закрытия определяет ваша политика слияния.

Жизненный цикл миссии

Миссия проходит пять фаз, показанных лентой в пульте миссии:

Анализ → План → Сборка → Приёмка → Деплой

• Анализ (опционально, analyze: true) — аналитик готовит требования, архитектурное решение и дизайн-документ, публикует их в вики, заводит задачи в трекере и создаёт тест-кейсы из функциональных требований. Если цель неоднозначна, миссия ставится на паузу с уточняющими вопросами.
• План — цель (или дизайн) разбивается на упорядоченные подзадачи.
• Сборка — подзадачи уходят кодер-раннерам; каждая возвращает ветку и структурированный отчёт.
• Приёмка — Mockarty запускает отдельную тестовую миссию и реально выполняет запрошенные функциональные, браузерные, нагрузочные, fuzz/security, chaos или contract-движки. Зелёная квитанция принимается только для точных namespace, mission, job, attempt, branch и commit и только когда каждый запрошенный движок вернул собственный сохраняемый артефакт. Отчёт кодера и необязательный model-review остаются советом. Красный независимый вердикт возвращает подзадачу с конкретными фактами; цикл ограничен лимитом попыток. Недоступная независимая проверка оставляет результат непроверенным и не может разрешить автоматический деплой.
• Запрос на слияние — когда все подзадачи приняты, Mockarty открывает merge/pull request и сохраняет его номер, целевую ветку, точный head и состояние слияния. Конфликт или изменившийся head блокируют слияние. Ссылка и состояние видны в миссии. При guardrail auto Mockarty может слить только бесконфликтный запрос, чей head всё ещё равен независимо принятому commit и у миссии нет непроверенных подзадач; по умолчанию требуется решение человека. Укажите openMr: "off", если запросами управляет ваша автоматизация. Повтор миссии не дублирует тот же запрос, а исправленный commit получает новую точную идентичность эффекта.
• Деплой — если задана цель деплоя, принятый код доставляется через SSH (скопировать артефакты на хост и запустить), Compose (загрузить docker-compose стек и docker compose up) или CI-пайплайн (дождаться собственного пайплайна компании на GitLab, GitHub Actions или Jenkins, засчитав успех только для точного принятого commit). Неизменяемый артефакт виден в mission.acceptedCommit; Mockarty отклоняет изменившуюся ветку, если она больше на него не указывает. Цель GitOps может закоммитить манифесты в репозиторий, за которым следит Argo/Flux, но сейчас она намеренно остаётся непроверенной, а rollback недоступен до сохранения точного GitOps deploy commit. Цель Kubernetes применяет манифест из рабочей копии через server-side apply и засчитывает успех только по kubectl rollout status для названной рабочей нагрузки — её проверкой служит сама раскатка. Если миссия должна завершиться проверенным деплоем, используйте CI с health URL, SSH/Compose либо Kubernetes. Продовые цели всегда ждут одобрения человека.

Ограничители исполнения действуют на всю миссию, включая восстановление после перезапуска admin-узла. maxAttempts по умолчанию равен 5 и принимает значения от 1 до 20 на подзадачу; отрицательные и большие значения отклоняются. У миссии также есть сохраняемый дедлайн активной работы и общий потолок диспетчеризаций, которые нельзя сбросить failover-восстановлением. Время операторской паузы не расходует активный дедлайн. Явный повтор человеком получает новое окно активного времени, но число таких повторов тоже ограничено; автоматическое подхватывание сироты использует только оставшийся сохраняемый бюджет.

Пульт миссии

Кликните по карточке миссии (или по кнопке раскрытия), чтобы открыть её пульт:

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

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

Доступные из пульта действия (в зависимости от состояния):

Когда повтор запрещён

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

Проверьте целевую систему сами и точно укажите результат. Если эффект не был
применён и повтор безопасен:

curl -X POST "$MOCKARTY/api/v1/coder/missions/$MISSION_ID/deploy-outcome" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"outcome":"not_applied"}'

Используйте applied, если проверка доказала, что исходное развёртывание было
применено. Тогда Mockarty завершит провалившуюся или прерванную миссию и не
отправит развёртывание повторно. Отменённая оператором миссия останется
отменённой, но сохранит факт применённого развёртывания. Значение обязательно,
попадает в журнал аудита с вашим именем; точный повтор безвреден, а противоречащее
второе утверждение отклоняется. Такое решение доступно только
владельцам/администраторам с правом на развёртывание. Агент вызывает
coder_mission_reconcile_deploy с тем же явным исходом. Эквивалент CLI:
mockarty coder-delivery missions reconcile-deploy MISSION_ID not_applied.

Для цели типа CI pipeline проверять вручную не обязательно: отправьте
{"outcome":"provider"}, и Mockarty спросит CI-систему (GitLab, GitHub или
Jenkins) о том самом пайплайне, прогоне или сборке, которые записал при отправке
развёртывания. Завершённое успешное выполнение закрывает миссию как applied по
записи самого провайдера; отменённое или пропущенное — как not_applied. Ещё
идущее выполнение возвращается как «ждите», а упавшая задача намеренно
остаётся за вами: упавший деплой мог применить часть шагов. У целей SSH, Compose,
GitOps и Kubernetes такой записи нет — для них остаётся явное applied /
not_applied.

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

Человек в петле

Миссии, которым нужны вы, всплывают карточками вверху страницы, считаются в индикаторе «Ждут вас» и приходят уведомлениями во входящие (и в подключённые каналы, например Slack или Telegram):

• Нужны ответы — аналитик задал уточняющие вопросы. Ответьте в карточке (или через coder_mission_answer) — миссия продолжится.
• Ждёт одобрения — деплой готов. Одобрите или отклоните из карточки (или через coder_mission_approve). Одобрять могут только владельцы/администраторы.
• На паузе — оператор осознанно остановил миссию. Продолжите её, когда зависимость будет готова, либо отмените, если работа больше не нужна.
• Прервана — прежнее выполнение нельзя безопасно продолжить после потери узла-владельца или неоднозначного внешнего эффекта. Повторите активный узел, чтобы создать новую fenced-попытку, либо отмените миссию. Mockarty не выдаёт это состояние за провал и не переигрывает прежний эффект молча.

Если очередь внимания не читается, страница показывает ошибку с повтором, а не пустую «здоровую» очередь.

Уведомления приходят и при завершении или провале миссии.

Честные вердикты

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

Кто исполняет подзадачу

По умолчанию каждую подзадачу собирает флот кодер-раннеров. Но один план миссии может сочетать разные возможности — задайте у подзадачи executor:

• runner (по умолчанию) — код пишет кодер-раннер.
• agent — подзадачу ведёт внутренний специалист Mockarty, а не пишет код: браузерный UI-тест (agentName: web_ui_tester), создание тест-кейсов (test_planner) и т. п. Его результат принимается (или перезапускается) так же, как задача кодера.
• remote — подзадачу исполняет внешний агент, подключённый по A2A (Admin → Remote Agents), выбранный по skillId подзадачи и необязательным меткам selector (например, region=eu). Так флот расширяется сторонними агентскими сетями.

Неизвестный executor безопасно откатывается к раннеру. Через MCP coder_mission_add принимает executor / agentName / skillId / verify / requiredChecks на задачу; декомпозер тоже может сам направить шаг специалисту.

Чем должна быть доказана подзадача

Подзадача может назвать движок тестирования, который обязан её подтвердить, — вместо просьбы прозой внутри prompt. Добавьте verify:

{
  "prompt": "Добавь эндпоинт /orders …",
  "verify": [
    {"engine": "functional", "ref": "orders smoke", "target": "http://localhost:8080", "note": "все запросы отвечают 2xx"},
    {"engine": "load", "note": "p95 меньше 300 мс"}
  ]
}

engine — одно из functional, load, fuzz, chaos, contract, ui_test, test_case, temporal_probe, bot_scenario. Движок, которого в этой установке нет, отклоняется при постановке подзадачи, а причина попадает в журнал миссии — обещания несуществующей проверки не будет. Кодер получает директиву конкретными вызовами инструментов Mockarty и обязан привести их результат в отчёте; если его набор инструментов до движка не дотягивается, он обязан прямо сказать это, а не выдать проверку за выполненную.

Дотягивается кодер до движков собственными инструментами Mockarty: раннеру выдаются группы знаний команды, моков, тестирования API, планов тестирования и наблюдаемости развёрнутой системы — с учётом того, что входит в ваш тариф. Администратор может изменить набор переменной окружения MOCKARTY_CODER_MCP_GROUPS на админ-узле (список идентификаторов групп через запятую, например processing,mocker,tester,testplan,observability,perf); идентификаторы групп возвращает GET /api/v1/mcp/groups.

Для детерминированной локальной проверки добавьте в подзадачу requiredChecks. Каждая проверка задаётся исполняемым файлом и аргументами, а не строкой оболочки:

{"requiredChecks":[
  {"name":"Модульные тесты Go","args":["go","test","./..."],"timeoutSeconds":900},
  {"name":"Go vet","args":["go","vet","./..."]}
]}

Админ отдаёт задачу только раннеру, который объявил нужную toolchain. Раннер выполняет проверки над закоммиченным результатом до push. Ненулевой код выхода запрещает публикацию и возвращает типизированный результат (имя, код выхода, время и дайджест вывода); диагностический текст ограничивается и очищается от секретов. Обёртки sh/bash отвергаются: очередь не может доказать, какую toolchain они скрывают.

Тот же payload можно добавить в живую миссию через CLI:

mockarty-cli coder-delivery missions add MISSION_ID --file follow-up.json

Go SDK

mission, err := client.CoderDelivery().AddToMission(ctx, missionID, mockarty.CoderMissionAddRequest{
    Tasks: []mockarty.CoderSubTask{{Prompt: "Запусти и почини модульные тесты", RequiredChecks: []mockarty.CoderRequiredCheck{{Name: "Модульные тесты Go", Args: []string{"go", "test", "./..."}}}}},
})

Python SDK

mission = client.coder_delivery.add_to_mission(mission_id, {
    "tasks": [{"prompt": "Запусти и почини модульные тесты", "requiredChecks": [{"name": "Модульные тесты Go", "args": ["go", "test", "./..."]}]}]
})

Java SDK

Map<String, Object> mission = client.coderDelivery().addToMission(missionId, Map.of(
    "tasks", List.of(Map.of("prompt", "Запусти и почини модульные тесты", "requiredChecks", List.of(
        Map.of("name", "Модульные тесты Go", "args", List.of("go", "test", "./...")))))));

Наблюдение за развёрнутым

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

curl -s -X POST http://localhost:5770/api/v1/observability/query \
  -H "X-API-Key: mk_ваш_токен" -H "Content-Type: application/json" \
  -d '{"source":"prometheus",
       "expression":"sum(rate(http_requests_total{code=~\"5..\"}[1m]))",
       "correlation":{"environment":"staging"}}'

SDK автоматически используют пространство имён клиента. В прямом HTTP-запросе
добавьте ?namespace=your-space, чтобы выбрать нужное пространство; у аккаунта
или API-ключа должен быть доступ к нему. Ключ, закреплённый за пространством,
не может запросить другое пространство.

sources, err := client.CoderDelivery().ObservabilitySources(ctx)
evidence, err := client.CoderDelivery().QueryObservability(ctx, mockarty.CoderObservabilityQuery{
    Source: "prometheus", Expression: "up",
    Correlation: mockarty.CoderObservabilityCorrelation{MissionID: mission.ID},
})

sources = client.coder_delivery.observability_sources()
evidence = client.coder_delivery.query_observability({
    "source": "prometheus", "expression": "up",
    "correlation": {"missionId": mission["id"]},
})

Map<String, Object> sources = client.coderDelivery().observabilitySources();
Map<String, Object> evidence = client.coderDelivery().queryObservability(Map.of(
    "source", "prometheus", "expression", "up",
    "correlation", Map.of("missionId", mission.get("id"))));

В CLI команда mockarty coder-delivery observe sources показывает привязанные источники. Сохраните JSON-тело из REST-примера в локальный файл и выполните mockarty coder-delivery observe query --file query.json.

GET /api/v1/observability/sources?namespace=sandbox перечисляет, что разрешено спрашивать этому пространству имён, и умолчания (последние 15 минут, 200 строк). По MCP та же пара — observability_sources и observability_query. Учётной записи нужно право на чтение модуля надёжности именно в фактически запрошенном пространстве имён. Если тело POST называет другое пространство, чем URL, право проверяется и для пространства из тела; доступ в другой команде его не заменяет.

Любой ответ ограничен и доступен только на чтение, и приходит с evidenceDigest — sha256 по запросу и результату, — чтобы показание можно было процитировать, а не пересказать. Обязательно хотя бы одно поле correlation (миссия, прогон развёртывания, дайджест релиза, тестовый прогон, трасса, окружение): свидетельство, которое некому приписать, отвергается, а не сохраняется. Метки корреляции должны быть простыми идентификаторами: метка в форме секрета или персональных данных отвергается с ошибкой валидации, но не сохраняется. Строки логов, процитировавшие секрет, возвращаются с замаскированным значением: одна шумная строка не обнуляет весь запрос.

«Ничего не настроено» — это тоже ответ. Установка без стека наблюдаемости возвращает пустой список источников и отвечает на запрос source_not_configured. Неисправный настроенный источник отвечает source_error (502): восстановите его и повторите запрос. Ни один из этих ответов не доказывает здоровье системы.

Источник настраивает администратор на админ-узле:

Привязка к пространству имён — граница безопасности, а не метка. Mockarty не переписывает произвольный PromQL, добавляя фильтр арендатора, поэтому настроенный Prometheus должен содержать только те данные, которые разрешено читать участникам привязанного пространства. Для пространств с разным доступом к мониторингу используйте отдельные установки админ-узла.

После развёртывания кодера Mockarty выполняет до трёх поведенческих health-проб в ограниченном окне. Если проба не прошла, система кратко читает совместимые источники наблюдаемости пространства миссии до отката, пока неисправный кандидат ещё работает. При успешных пробах источники читаются до приёмки. Явные события error/fatal или нездоровая метрика up тоже запускают откат. Ограниченная попытка исправления с повторным развёртыванием разрешена только после того, как восстановленная цель прошла собственное окно проверки; недоступный откат явно объявляется невозможным, а неподтверждённый требует сверки перед повтором. В миссии остаются счётчики источников и замороженные дайджесты свидетельств, в том числе запись в таймлайне о неисправном кандидате, когда его результат уже заменён успешным исправлением. Сырые ответы систем наблюдаемости и учётные данные не копируются в инструкции для исправления. Отсутствие источника, пустой или усечённый ответ остаются not_evaluated и не превращаются в «здорово».

Командные скиллы

Помимо встроенных скиллов кодера, миссия может подтянуть установленные скиллы вашей команды из маркетплейса — чтобы кодер работал так, как принято у вас. Передайте skills (список имён скиллов) в coder_mission_start — каждый названный установленный скилл материализуется в песочницу кодера рядом со встроенными, и движок подгружает его по мере надобности. Провизятся только скиллы, установленные в вашем пространстве имён и покрытые лицензией; имя, которого у вас нет, тихо игнорируется. Так вы учите автономного кодера вашим соглашениям (скилл со стилем кода, доменный чек-лист) без изменения продукта.

Настройка доставки

Delivery config (в шапке страницы) описывает, как ваша компания выпускает код: репозитории, доступные кодеру, цели деплоя (SSH / Compose / GitOps / CI-пайплайн / Kubernetes), защищённые ветки и заметки об инфраструктуре, которые кодер читает как контекст. Учётные данные указываются по идентификатору из хранилища секретов — они не вводятся и не отображаются здесь. Команды целей проверяются на опасные операции до сохранения конфигурации.

Менять эту конфигурацию, запускать миссию с возможной доставкой и подтверждать развёртывание может только владелец или администратор. Явно добавьте каждый разрешённый репозиторий: миссия должна использовать один из этих точных адресов. Не включайте учётные данные в URL репозитория. Для каждой цели выберите в интерфейсе политику подтверждения. Одного отзыва ИИ-модели для автоматического развёртывания недостаточно: без отдельной доверенной проверки качества (AQC) Mockarty попросит подтверждение человека.

GitOps пока умеет записать эффект в репозиторий манифестов, но не подключён к статусу Argo CD или Flux. Один commit не доказывает, что контроллер применил его в кластере, поэтому API Delivery Config отклоняет GitOps-цель развёртывания ещё до сохранения. Метаданные GitOps можно оставить для планирования, но для автономного развёртывания до появления наблюдения контроллера нужна поддерживаемая цель с реальной проверкой.

Для целей SSH и Compose обязателен healthCmd, для CI — healthUrl; цель Kubernetes проверяется раскаткой названной рабочей нагрузки и не требует ни того, ни другого. API отклоняет непроверяемую цель до сохранения, а проверка во время развёртывания остаётся защитой для старых записей. Это намеренно: загрузка файлов, запуск процесса или зелёная сборка сами по себе не доказывают, что доставленное приложение доступно и исправно.

Для GitLab CI, GitHub Actions и Jenkins Mockarty сохраняет точный, не содержащий учётных данных идентификатор выполнения сразу после того, как провайдер принял запуск. Поэтому после перезапуска admin-узел может найти и отменить тот же пайплайн, workflow run, элемент очереди или build. Принятый запрос отмены ещё не считается завершением: Mockarty ждёт terminal-состояние именно этого выполнения у провайдера. Если корреляция, поиск или подтверждение terminal-состояния неоднозначны, миссия остаётся в unknown и требует сверки; Mockarty не запускает деплой повторно молча.

Стандартный запуск Compose (docker compose up -d) имеет точное ограниченное по времени обратное действие для того же каталога и Compose-файла: если проверка отменена или завершилась ошибкой, Mockarty выполняет docker compose down, даже когда контекст миссии уже отменён. Для собственного startCmd укажите точный rollbackCmd; Mockarty не угадывает, как отменять операторскую команду.
После стандартного отката Compose Mockarty трижды проверяет, что у этого стека не осталось контейнеров. Если подтвердить состояние не удалось, откат остаётся непроверенным и автоматический повтор задерживается. Пользовательский откат проверяется через healthCmd; настройте команду так, чтобы она проверяла нужное восстановленное состояние.

Секция Настройки автономности продукта задаёт два умолчания для всех
автономных миссий пространства: политику охранников (поставить миссию на
паузу и спросить человека — или предупредить и продолжить) и окно прогона
в минутах (миссия, работающая дольше, упирается в стену времени). Отдельный
продукт может их переопределить: агент пишет собственную группу delivery
config этого продукта через coder_delivery_config_set с productId (или
через REST API), и она побеждает умолчание пространства для миссий этого
продукта. Порядок слоёв: сначала значение миссии, затем продукта, затем
пространства, затем установки. Чипы контекста продукта на странице миссий — или агентский
инструмент mission_settings_effective — показывают каждое выбранное значение,
задавший его уровень и runtimeApplied. Срок хранения применяется как живая
политика очистки пространства/установки, а не как настройка продукта или одной
миссии. Задайте его в Автономные миссии → Лимиты и настройки, оставьте поле пустым
для наследования либо используйте mockarty-cli autonomy settings set. Активная
юридическая блокировка сохраняет подходящие миссии кодера, задания, входные
свидетельства и строки журнала даже после обычного срока.

Секция CI/VCS — {"system":"gitlab","baseUrl":"https://gitlab.company.internal","credRef":"…"} — это то, что позволяет Mockarty говорить с вашим форжем: открывать запрос на слияние по завершённой миссии и, при autoReviewMRs: true, ревьюить каждый запрос, который открывает команда. Добавьте "openMr":"off", если открывать запросы вы хотите сами.

У каждой цели — небольшой JSON-конфиг. Примеры:

• SSH / Compose — {"host":"deploy.example.com","user":"deploy","targetDir":"/opt/app","mode":"compose","composeFile":"docker-compose.yml","hostKey":"…","healthCmd":"curl -sf localhost:8080/health"}
• CI-пайплайн — {"system":"gitlab","baseUrl":"https://gitlab.company.internal","project":"team/app","healthUrl":"https://app.example.com/health"} (system = gitlab | github | jenkins; ветка по умолчанию — доставленная). Для GitLab используется точный pipeline ID из ответа на trigger. Для GitHub обязательны workflow, input workflow с именем mockarty_delivery_id и run-name: ${{ inputs.mockarty_delivery_id }}: Mockarty сверяет это имя прогона и принятый commit. Для Jenkins Mockarty следует от queue item из ответа trigger к точному executable number и проверяет MOCKARTY_COMMIT. Деплой считается завершённым только после связанного прогона и health-check. API-токен CI задаётся ссылкой на credential у target; inline-токены в JSON отклоняются.
• Kubernetes — {"context":"prod","namespace":"payments","manifestPath":"deploy/app.yaml","workloadKind":"deployment","workloadName":"payments-api","rollbackRevision":7,"timeoutSeconds":300}. workloadKind = deployment | statefulset | daemonset; manifestPath — путь относительно доставленной рабочей копии, не больше 4 МиБ; rollbackRevision обязателен и должен указывать на существующую ревизию раскатки — именно к ней возвращает откат. fieldManager по умолчанию mockarty, timeoutSeconds — 300 (допустимо 10-900). Kubeconfig задаётся ссылкой на credential у target; если Mockarty работает внутри того же кластера, вместо этого укажите "inCluster": true. Откат выполняет rollout undo к точной ревизии и заново проверяет раскатку: неподтверждённая раскатка сообщается как неизвестный исход, а не как успешный откат. Цели Kubernetes нужен kubectl на машине, где работает Mockarty; без него деплой сообщается как не дошедший до кластера, а не как неопределённый исход.

Для SSH и Compose targetDir должен быть абсолютным путём и не должен разрешаться в корень файловой системы (например, /opt/app/../.. отклоняется).

REST-поверхность: /api/v1/coder/delivery-config и /api/v1/coder/missions. В Go, Python и Java SDK она доступна как CoderDelivery() / coder_delivery / coderDelivery(). CLI предоставляет те же ограниченные операции:

mockarty-cli coder-delivery config get
mockarty-cli coder-delivery config put --file delivery-config.json
mockarty-cli coder-delivery config delete --product-id PRODUCT_ID
mockarty-cli coder-delivery missions start --goal "Выпустить принятый commit" --repo https://git.example/app.git --target staging --product-id PRODUCT_ID
mockarty-cli coder-delivery missions list
mockarty-cli coder-delivery missions get MISSION_ID
mockarty-cli coder-delivery missions add MISSION_ID --file follow-up.json
mockarty-cli coder-delivery missions approve MISSION_ID
mockarty-cli coder-delivery missions deny MISSION_ID

Тот же запрос запуска доступен через REST и все поддерживаемые SDK. URL
репозитория должен точно совпадать с репозиторием в выбранном Delivery Config;
productId выбирает config конкретного продукта, если он задан.

REST

curl -X POST "$MOCKARTY_URL/api/v1/coder/missions?namespace=default" \
  -H "X-API-Key: $MOCKARTY_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"goal":"Выпустить принятый commit","repoUrl":"https://git.example/app.git","deployTarget":"staging","productId":"PRODUCT_ID"}'

Go SDK

mission, err := client.CoderDelivery().StartMission(ctx, mockarty.CoderMissionStartRequest{
    Goal: "Выпустить принятый commit", RepoURL: "https://git.example/app.git",
    DeployTarget: "staging", ProductID: "PRODUCT_ID",
})

Python SDK

mission = client.coder_delivery.start_mission({
    "goal": "Выпустить принятый commit",
    "repoUrl": "https://git.example/app.git",
    "deployTarget": "staging",
    "productId": "PRODUCT_ID",
})

Java SDK

Map<String, Object> mission = client.coderDelivery().startMission(Map.of(
    "goal", "Выпустить принятый commit",
    "repoUrl", "https://git.example/app.git",
    "deployTarget", "staging",
    "productId", "PRODUCT_ID"
));

Модели и мощности раннеров

Откройте Мощности в Автономных миссиях. На одной панели видны подключённые раннеры, доступные слоты, очередь заданий и модель каждого компонента — декомпозиции, приёмки, код-ревью и сборки на раннерах. Владелец пространства может прямо здесь добавить write-only профиль модели и сразу назначить его; общие профили установки остаются под управлением администратора. Весь трафик идёт через LLM-шлюз Mockarty: он маскируется гардрейлами, учитывается в леджере расхода и переключается централизованно — смените назначение, и все вызовы перейдут на выбранную модель.

Результаты раннера и восстановление

Каждое выполнение использует отдельный закрытый рабочий каталог. Повторная попытка не перезаписывает файлы, сохранённые от предыдущей. Раннер сохраняет неопубликованные коммиты и результаты неудачной работы после получения репозитория для восстановления. Успешно опубликованную работу или успешный прогон без изменений можно очистить после сохранения итогового отчёта вне этого каталога.

Для одиночного запуска CLI используйте --report с путём вне рабочего каталога. Без внешнего места сохранения отчёта рабочий каталог остаётся на диске. --keep-workspace также отключает автоматическое удаление. Сохранённые каталоги занимают место и могут содержать чувствительные файлы задачи или логи: ограничьте доступ и перед удалением заберите нужный код и логи. Это не автоматическая удалённая резервная копия артефактов.

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

Измерение эффекта

Два источника данных дашбордов (Дашборды → добавить виджет → «Автономный кодер») оцифровывают автономную работу:

• LLM-стоимость миссий кодера — токены по миссиям за период, крупнейшие потребители сверху.
• Миссии кодера: сэкономленные человеко-часы — оценки связанных задач минус время миссий до завершения. Период определяется датой завершения, поэтому последующие обновления не переносят миссию в другой период. Для миссии без оценки учитывается фактическое время, но оценка человека не придумывается; итог может быть отрицательным.

Счётчики Prometheus (/metrics) покрывают миссии по статусам, длительности, перезапуски и принятые без проверки — для вашего собственного мониторинга.

MCP-инструменты

Весь жизненный цикл миссии доступен агентам: coder_mission_start, coder_mission_status, coder_mission_answer, coder_mission_approve, coder_mission_pause / resume / skip / add / retry / restart_from / reconcile_deploy / cancel, coder_mission_diagnose, а также coder_analyze, coder_review_mr, coder_ingest_artifact и пара инструментов настройки доставки.

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

• Пользовательские дашборды — виджеты эффективности.
• Автономный агент — автономный тестировщик.
• Уведомления — подписка событий миссий на каналы.